Hi, As i remember GoF descibes the reason.It was something like this....that Inheritence breaks encapsulation b/c subclass expose the parent class methods and properties.Therefore Parent's class encapsulation is breaked!. Note:For more clear reason see GoF. Bye, Viki.
Originally posted by Vikrama Sanjeeva: Hi, As i remember GoF descibes the reason.It was something like this....that Inheritence breaks encapsulation b/c subclass expose the parent class methods and properties.Therefore Parent's class encapsulation is breaked!. Note:For more clear reason see GoF. Bye, Viki.
Ooops, I do not have the GoF and I am not satisfied by explanation: how may subclass disclose more about superclass than superclass itself? BTW, is this conversation really about objects or instances (rather than class)?
Inheritance can sometimes break encapsulation. The idea is if the implementation (but not the exposed public methods ) of base class changes, the subclass may break. Say you have superclass A and subclass B. In B you add a private method foo. Now if the implementation of A changes so that it also adds a method foo with same signature as in B, but foo in A is declared protected then B will break because you cannot override foo in B with more restrictive visibility than in A. HTH -Roshan
Originally posted by Jose Botella: Why inheritance breaks encapsulation? Isn't encapsulation achieved via private members? If so, private members aren't accesible from subclasses either.
Also, if you add a method to a super class which already exists in a subclass (without you noticing), you might get some weired results because of the unexpected overriding.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja and Junilu, thanks. I am ovewhelmed by your all your links but I shall be back. Do not relax!
Joined: Aug 30, 2001
Originally posted by Roshan : but foo in A is declared protected then B will break because you cannot override foo in B with more restrictive visibility than in A.
. It is just the compilation error. After this either you remain with a previously compiled application or you correct the eror. Nobody is hurt. Broken code does not illustrate broken encapsulation. Ilja Preuss: Ibid. Broken code does not illustrate, at least to me, broken encapsulation.
Snyder's article dates to 1986 and completely irrelevant to Java. It states that client of class may access instance variables only through methods (not the case in Java, cf. public) and encapsulation is broken, because designer can't prevent inheritance of instance variables and/or methods (again wrong for Java. Cf. private).
I haven't Joshua Bloch's book.
I do not see how the encapsulation may be broken through inheritance. Let me cite more relevant to Java:
Originally posted in Mark Grand, Patterns in Java: a catalog of reusable design patterns illustrated with UML, Volume 1. - 2nd ed., 1999, John Wiley & Sons p.55 "There is no way effectively hide methods or variables that are inherited from a superclass"
Agree. But it is because, designer of superclass, did not bother to hide them by using private. It cannot be judged as "break of encapsulation" because the data in supercalss was not encapsulated in first place.
Originally posted in Mark Grand, Patterns in Java: a catalog of reusable design patterns illustrated with UML, Volume 1. - 2nd ed., 1999, John Wiley & Sons "An even more serious problem is that client classes can call the public methods of the utility superclass, which defeats its encapsulation"
"Defeats"? Where? It was NOT encapsulated in supercalss, because it had public modifier and could be reachable in superclass outside of inheritance. I still cannot understand. Protected or public members (in supercalss) are accessible by objects of another classes and therefore are not encapsulated. There is no sense in claiming the break of absent encapsulation.
Now if the member is private and therefore encapsulated, it is not available through subclass/inheritance. Where is the break? OK, after writing this I found http://www.coderanch.com/t/96837/patterns/Composition-versus-Inheritance that expalined me what I known, i.e. that inheritance is not good but I really had never used it before. Still without explanation how inheritance breaks encapsulation
Guennadiy, I think Snyder's article is still relevant to Java--Joshua Bloch even references that article in his book. Snyder wrote:
Encapsulation is a technique for minimizing interdependencies among separately-written modules by defining strict external interfaces. The external interface of a module serves as a contract between the module and its clients, and thus between the designer of the module and other designers. If clients depend only on the external interface, the module can be reimplemented without affecting any clients, so long as the new implementation supports the same (or upward compatible) external interface.
The key phrase to understanding the reason for inheritance breaking encapsulation is "minimizing interdependencies." While the problem of inherited instance variables may be eliminated in Java by making them private, encapsulation can still be broken or weakened whenever a method is overridden by subclasses because interdependencies between the subclasses and the superclass may be introduced: 1. if the subclass invokes superclass methods 2. if the superclass "self-uses"/invokes overridable methods. When these kinds of interdependencies are introduced between superclass and subclasses, then it will become difficult or even impossible to change the superclass without making corresponding changes to subclasses. Hope this helps,
I see how Inhertiance "can" break Encapsulation but the statement Inheritence breaks encapsulation makes it sound like it "always" breaks encapsulation. To make sure I'm on the same page, and please correct me if I'm wrong; encapsulation means you can't change/access the internal state of an object without going through the object's public api - assuming the instance members have private access. If I can change the internal state without going through the public api then I'm able to break encapsulation. So what comes to my mind where Inheritence can break Encapsulation is when a Superclass method calls a method that is overridden in the subclass and the super class method passes in a reference/shallow copy (not a deep copy) of the private members of the object into the overridden method. Now the overridden subclass method has access to the internal state of the superclass without having to go through the public api presented by the superclass. This break of encapsulation can happen in vice versa. If I ensure deep copies in these interdepencies, I couldn't change the internal state/private instance members - so I couldn't break Encapsulation via Inheritance. So inheritance can break encapsulation the same way an accessor method that returns a shallow copy of an object's internal state breaks encapsulation but not always.