Is defining get/set methods for every field overkill?

FeepingCreature feepingcreature at gmail.com
Wed Nov 23 09:51:46 UTC 2022


On Tuesday, 22 November 2022 at 21:45:29 UTC, []() {}() wrote:
> On Tuesday, 22 November 2022 at 21:00:58 UTC, []() {}() wrote:
>>
>
> "Being able to declare a “friend” that is somewhere in some 
> other file runs against notions of encapsulation." (This is the 
> motivation for that article it seems).
>
> I completely disagree with the assertion.
>
> C++ Friend notion does not, not by any means, run against the 
> notion of encapsulation.
>
> Sure, it expands the perimeter (i.e. it puts a door in the 
> wall).
>
> But, and this is my point, there is a guard standing at the 
> door. And that guard knows who has been authorised to pass 
> through it. The encapsulation remains. Only its perimeter has 
> been expanded.
>
> One could argue that D's approach is just that. It expands the 
> perimeter to the module level. But there's no guard at the door 
> in D.
>
> Surely, this 'let anyone pass through' design, decreases 
> encapsulation? How could it possibly increase encapsulation, as 
> claimed, by the author of that article?
>
> If there were a means in the language for controlled sharing 
> within a module, *that* would increase encapsulation.

The module is the capsule. D is simply not interested in building 
a capsule around a class. D does not let "anyone" pass through, 
it lets "anyone in the module" pass through, because the module 
is the wall. I think this is a stronger concept of encapsulation 
than C++ friends because the encapsulation is lexical rather than 
just declarative.


More information about the Digitalmars-d-learn mailing list