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