how to make private class member private
Mike Parker
aldacron at gmail.com
Tue Mar 13 06:03:11 UTC 2018
On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
>
> 1st - D has broken the concept of class encapsulation, simply
> for convenience at the module level. Not good in my opinion.
No, it hasn't broken encapsulation. Encapsulation is at the
module level. A class or struct and any supporting functions can
be included in a single module and the private API is
encapsulated from the outside world.
>
> 2nd - C++/C#/Java programmers will come to D, use the same
> syntax, but get very different semantics. Not good in my
> opinion. (i.e. I only realised private was not private, by
> accident).
D is not C++, C#, or Java. C++ uses friend to get around the
issue. Java has no solution. I don't know about C#.
>
> D has made many good design decisions. I do not see this as one
> of them.
I think it's a great feature and I use it frequently. It's allows
more flexibility in class design. Without it, we'd need another
protection attribute to enable the concept of "private to the
module".
In Java, it's recommended to manipulate private member variables
through their accessors even in methods of the same class. I've
always found that extreme. If you need to make a breaking change
to the member variable, you already have access to all of the
method internals anyway. Yes, there's room for error if you
forget to make a change, but with all the support in modern IDEs
and editors for find/replace, it's a simple matter to handle it
all at once. And in the standard edit-compile-run cycle, any
breakage is discovered right away, not weeks down the road in the
field.
The same applies here. Encapsulation simply isn't broken by this
feature.
More information about the Digitalmars-d-learn
mailing list