From: Robert Klemme <shortcutter@...>
Date: 2006-12-30T00:20:05+09:00
Subject: Re: Paper on strong Object Oriented Encapsulation (Was: some subject with needless insults)

On 29.12.2006 10:36, Neil Wilson wrote:
> It's a throwback to the C line of languages.
> 
> In Eiffel, for example, there is no real way of hiding methods from
> your descendants.

As a side note: in Java, by marking something "private" you effectively 
make it invisible for subclasses; you cannot access private members from 
there and consequently they cannot be overridden.

> All you can do is 'freeze' a particular feature. And that is
> deliberate. Inheritance is after all about the 'is a' relationship.
> There is no real need to hide methods from classes that are essentially
> genetically identical to you.

Funny that you should mention Eiffel.  Betrand Meyer is one of the guys 
who actively advocate implementation inheritance - and that's why you 
can create subclasses of superclasses which do not follow the general 
"is a" contract (i.e. are no supertypes of the super class's type).  You 
can make methods private (by changing their export status) for example 
and thusly change the public interface (and the type).

But - as you said - the choice is *always* the subclass creator's.  He 
explicitly states "Inheritance is the embodiment of the Open-Closed 
principle: a mechanism that enables you to pick an existing class, 
written yesterday or twenty years ago by you or by someone else, and 
discover that you can do something useful with it, far beyond what had 
been foreseen by the original design. Letting a class author define what 
eventual descendants may or may not use would eliminate this basic 
property of inheritance." [1]

> If you want encapsulation use delegatation, not inheritance.

Yuck.

> IMHO one of the problems with static languages is that they elevated
> the notion of inheritance to a level it was never originally intended
> for - system correctness - rather than just a nifty shorthand that
> eliminates a bundle of duplication.

I'm not sure I agree 100% here.  The "nifty shorthand" is certainly one 
part of it (Bertrand Meyer calls it "implementation inheritance").  But 
"interface inheritance" (and thus inheritance of the contract) 
definitively plays more in the correctness area as it establishes a 
relationship between types (namely the subclass or descendant is a 
supertype of the ancestor).

Another side note: for everyone interested in concepts of object 
orientation OOSC is a very valuable read.  Bertrand Meyer covered all 
the concepts involved and he is very good at analyzing and separating 
out concepts.  I always enjoy reading and rereading his book.

Kind regards

	robert

[1] section 16.8., OOSC by Betrand Meyer, 2nd ed