On Wed, 17 Apr 2013 12:17:03 +0100, Tofu Ninja <emmo...@purdue.edu> wrote:
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.
No, I got all that :)
My point was that it can in fact make your program run faster, indirectly.
:P
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
