Ref and class function calls?
Tofu Ninja
emmons0 at purdue.edu
Wed Apr 17 04:17:03 PDT 2013
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.
More information about the Digitalmars-d-learn
mailing list