On Wednesday, 17 April 2013 at 11:02:24 UTC, Regan Heath wrote:
True, but this is what I'd call a short term view of
encapsulation and code quality.
Thinking about encapsulation in the short term is important
because it forces you to properly design things for the long
term. If you don't care at all about encapsulation (or
orthogonality) you probably wont bother to actually define the
interface between two potentially orthogonal pieces of code.
If there is no separation "designed in" to start with then code
tends to tie itself together in sometimes surprising ways
typically creating unintended dependencies or complexity.
Essentially the code becomes harder to reason about, harder to
change and therefore harder to improve.
So, ultimately encapsulation (one aspect of good design) should
lead to code which is better in every measurable way, including
running faster. Sure, there will be the odd case where
encapsulation decreases performance, in those cases I would
take the practical route of breaking encapsulation to solve the
issue. In short, encapsulation is important and useful but not
paramount.
:)
R
You misunderstand me, I think encapsulation is great and
important, but just not as great and important as a lot of people
seem to think. I agree that encapsulation has a lot of good
qualities, but i also think it would be a little naive to say
that it doesn't have some bad qualities as well. All i am going
to say... really doesn't have much to do with the thread.
