🚀 go-pugleaf

From: Jos Warmer <jos@cs.vu.nl>
Date:     Mon, 21 Nov 88 10:24:59 MET

Having read and enjoyed the book 'Oject Oriented Software Construction'
of Bertrand Meyer, I have some questions/remarks about (multiple)
inheritance and safety.

At page 241 of Bertand Meyer's book an alternate definition is
given for STACK2 (page 118): the class FIXED_STACK.  It is declared
an heir of class ARRAY, instead of a client.

As far as I can see this definition of FIXED_STACK has a serious
safety-leak, as opposed to the definition of STACK2 at page 118.

Consider the following piece of (pseudo) eiffel code:

    a : ARRAY[INTEGER];         -- declare an entity of type ARRAY
    f : FIXED_STACK[INTEGER];   -- declare an entity of type FIXED_STACK

    f.Create;        -- created a fixed stack
    f.push(12);      -- top of stack is now 12

    a := f;          -- allowed, because FIXED_STACK is descendant of ARRAY
    a.enter(1, 20);  -- enter is allowed on ARRAY's

    value := f.top:  -- this will deliver value 20, instead of the previously
                     -- entered 12.

This example shows that any client of FIXED_STACK can manipulate its
implementation.
This is clearly not what is intended for the class FIXED_STACK. It
doesn't behave like a stack anymore.  The FIXED_STACK class has no way
to enforce its own semantics.  This is dangerous.
In this case the rule at page 333 should be applied:

    'inheritance means "is", client means "has".'

A FIXED_STACK has an array as it's implementation.  It ** is not **  an ARRAY.
In the discussion at page 333 the safety-aspect of the solution for
FIXED_STACK is not considered.
The disadvantage clearly outperforms two of the advantages mentioned:

The advantage of having a simpler way of accessing the array features
is superficial.
The reason that inheritance is more efficient is not to the point.
Whether inheritance or buying should be used must only depend on
design-criteria, not on efficiency. This attitude is correctly
expressed at page 344:

    "An object-oriented environment in which designers would have to think
     twice before adding an inheritance level because it would mean degraded
     performance would be rather unpleasant."

It is not clear whether the flexibility obtained by inheritance is an
advantage or not.

Also, the book advocates safe programming by the use of pre- and post-
conditions and assertions.  When you think this way, the FIXED_STACK
solution should be considered bad.

Maybe another rule can be formulated, in choosing between inheritance
or buying:

    "If a class B needs class A, then B should not be an heir of A if
     any operation on A corrupts the intended semantics of B.  In these
     cases B should be a client."

This rule can be seen as an extension of the "is-a" versus "has" rule.
Any comments, or different opinions?

				    Jos Warmer
				    jos@cs.vu.nl (via mcvax)