It has been argued that InheritanceBreaksEncapsulation because the SuperClass is not well encapsulated from the SubClass:

http://www.ccs.neu.edu/research/demeter/papers/context-journal/node17.html

''Inheritance creates a tight coupling between base and derived classes.  Whether or not that is good or bad depends on the nature of what you are trying to do; there are cases where delegation might be more appropriate, and there are cases where inheritance is GoodEnough.''

* And there are cases where tight coupling is ''preferable'', either for performance reasons, or because two or more classes are intended to be used in tandem.  The class is not always the proper GranuleOfRelease.


Encapsulation and InformationHiding aren't absolutes, otherwise it would be a violation for the author of the code to lay eyes on any of the classes he writes.

So to avoid that reductio ad absurdum, one needs to drill down to see what purpose encapsulation is supposed to achieve, and '''then''' ask whether e.g. inheritance violates that purpose -- not whether it violates the superficial definition.


----
''The class is not always the proper GranuleOfRelease''

Especially if you make a lot of classes because you have classes
with few responsibilities. Then they need to cooperate and they
can cooperate at the friend level because they are written
to work together. See TightGroupOfClasses.

Indeed, at least in C++ wise use of ''friend'' improves encapsulation.  http://www.parashift.com/c++-faq-lite/friends.html#faq-14.2

''And conversely, unwise use of "friend" makes encapsulation a lot worse. It's one of the many C++ two-edged swords. Often it's a way to simulate MultiMethods -- which perhaps goes to the heart of why classes aren't always the right unit.''

Unwise anything is bad.

''Sigh. That's not the point. The point is that "friend" is '''generally''' a bad thing. Its wise uses are very much in the minority.''

''The rest of the point is that it is a botched part of the design of C++; it wouldn't be necessary if MultiMethods had been in C++ in the first place.''


* I can think of wise use of friend besides MultiMethods; the PimplIdiom is one.  (friend isn't necessary there, as one can make the "impl" class features public; but if one wants to enforce the HandleBodyPattern, making the body a friend of the handle is one way to do it).  However, the times I am tempted to type "friend" are few and far between; a good question to ask is:  "How many members of class X would I have to make public in order to avoid making X a friend of Y; and if I did so, what likely would happen?''  See also PackageClass