Object Oriented Programming with D Language. Private access specifier.

[Neil Vice]

DF wrote:
> Robert Fraser Wrote:
> 
>> DF wrote:
>>> Why can private fields be accessed from other methods or classes in the same module?
>>>
>>> If I wanted to access them from the same module I would make them package public.
>> It's a feature -- a replacement for "friend" in C++. The general idea of 
>> a module is that it is an autonomous code unit controlled by a single 
>> developer/team and if you're accessing a private function in the module, 
>> you have a good reason to. It's all the same file, so if you're changing 
>> something that accesses a private member, you can change the private 
>> implementation as well.
>>
>> "package" isn't implemented (sadly -- I find it very useful in Java so 
>> that a package has only a single public API).
> 
> Ok, thanks for your reply. But I think you've missed one thing. Let's now speak of OO systems, about one basic principle of such systems which is data abstraction. According to it an object should not expose any of its implementation details. This means that you should completely hide the way in which an object implements a message handler from the rest of the program.That's one reason why all of your instance variables (a class's nonconstant fields) should be private.
> So what do you think on that D implementation of "private" access specifier breaks data abstraction?

If you implement a single class per module it isn't broken.

By implementing multiple classes in a single module, as previously 
mentioned you are indicating that you consider the classes part of a 
single set of "implementation details" which are then hidden from other 
modules, again not broken.

In this way it allows you to declare the level at which information 
hiding should be enforced.