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