File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Inheritance and encapsulation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Inheritance and encapsulation" Watch "Inheritance and encapsulation" New topic
Author

Inheritance and encapsulation

Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Why inheritance breaks encapsulation? Isn't encapsulation achieved via private members? If so, private members aren't accesible from subclasses either.


SCJP2. Please Indent your code using UBB Code
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
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.


Count the flowers of your garden, NOT the leafs which falls away!
Prepare IBM Exam 340 by joining http://groups.yahoo.com/group/IBM340Exam/
Guennadiy VANIN
Ranch Hand

Joined: Aug 30, 2001
Posts: 898
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)?
Roshan Lal
Ranch Hand

Joined: Nov 13, 2001
Posts: 64
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.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4419
    
    5

Here's the paper by Alan Snyder that is often referenced: http://www.cs.colorado.edu/~diwan/class-papers/snyder.pdf
Also, Joshua Bloch discusses concrete Java examples in his book "Effective Java Programming Language Guide" (Items 14 & 15)


Junilu - [How to Ask Questions] [How to Answer Questions]
Guennadiy VANIN
Ranch Hand

Joined: Aug 30, 2001
Posts: 898
Ilja and Junilu,
thanks. I am ovewhelmed by your all your links but I shall be back. Do not relax!
Guennadiy VANIN
Ranch Hand

Joined: Aug 30, 2001
Posts: 898
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.
Originally posted by Junilu Lacar:
Here's the paper by Alan Snyder that is often referenced: http://www.cs.colorado.edu/~diwan/class-papers/snyder.pdf
Also, Joshua Bloch discusses concrete Java examples in his book "Effective Java Programming Language Guide" (Items 14 & 15)

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
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4419
    
    5

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,
Chris Anteola
Greenhorn

Joined: Oct 27, 2010
Posts: 1
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.


AntyDigital
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Inheritance and encapsulation
 
Similar Threads
What are the principles of OOA/D?
inheritance violates encapsulation
4 key points about Oops
Field hiding
OO - where to start