Object Oriented Programming with D Language. Private access specifier.

[DF]

Lars Ivar Igesund Wrote:

> DF wrote:
> 
> > Fawzi Mohamed Wrote:
> > 
> >> On 2008-08-21 09:59:35 +0200, DF <deefriend at ymail.com> said:
> >> 
> >> > 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?
> >> 
> >> There can be good reasons to break encapsulation (see C++ friend method).
> >> A language should make it easy to respect successful practices, support
> >> them, but not needlessly limit the programmer.
> >> A programmer should be a grown up person, as long as it is clear what
> >> is ok and what not, and doing the right thing is easy, all should be
> >> well.
> >> In Python for example all variables are actually private just by
> >> convention...
> >> 
> >> I find D approach very reasonable, it forces all the things that know
> >> the private interface to be in one place, namely one file.
> >> Suppose that you need to write a template specialization that needs
> >> access to private details... D approach is well suited.
> >> 
> >> Fawzi
> >> 
> > 
> > Nice reply. "A programmer should be a grown up person..." who told you
> > that? :) Just a joke.
> > 
> > "There can be good reasons to break encapsulation (see C++ friend
> > method)." - it is sad that you think so.You mixed up a good design
> > solution and a solution. (Here I want to say that PROBABLY you've designed
> > your OO system in a wrong way if you need to break an encapsulation).
> > 
> > And I don't believe that one can't write "a template specialization that
> > needs access to private details" in Java. (Where "private"  - restricts
> > the access to the class itself. Only methods that are part of the same
> > class can access private members.)
> 
> OO isn't the answer to everything - and Java's definition of OO is only one
> interpretation, and not necessarily the best. Java's strictness can in fact
> force you to unnecessarily complex design aka bad design.
> 
> -- 
> Lars Ivar Igesund
> blog at http://larsivi.net
> DSource, #d.tango & #D: larsivi
> Dancing the Tango

"OO isn't the answer to everything" - nobody said that. Just we speak about writing OO systems in D language not about that OO is the answer to everything.
What considers Java I didn't write that Java is the best "definition of OO".

Java's strictness can in fact
force you to unnecessarily complex design aka bad design - please give me an example.