Re: Real OO

[stt@henning.camb.inmet.com (Tucker Taft)]

Richard Riehle (rriehle@nunic.nu.edu) wrote:
: ...
:   Though the substitutability principle is often attributed to Liskov,
:   it is also given treatment in a paper from Wegner and Zdonic,
:   "Inheritance as an Incremental Modification Mechanism" published in
:   the Proceedings of the European Conference on
:   Object-Oriented Programming, 1988.

:   An important overview of this subject is Cardelli and Wegner, "On
:   Understanding Types, Data Abstraction, and Polymorphism," ACM
:   Computing Surveys, Number 17, 1985.


:   -- =================================================================

:   All that academic stuff aside, the substitutability rule is quite
:   useful when trying to determine whether one is organizing a set of
:   objects by classification or by some other mechanism.  In particular,
:   there is a point-of-view which says one should always apply the
:   substitutability principle when attempting multiple inheritance.

In Ada 95, the substitutability rule is almost a tautology,
if you interpret it as meaning that any place where you can
use A'Class, you should be able to substitute an operand of
type A1'Class, where A1 is a derivative of A.  Since A'Class is a 
proper superset of A1'Class, it is trivial to show that any
procedure that works properly over all operands of "type" A'Class,
will also work properly over all operands of "type" A1'Class.

What this highlights, in my view, is that the substituability rule
only makes sense in terms of an *explicitly* enumerated set of 
properties or invariants that are presumed over a given set of types.  

If you then want to add a new type to that set, you must be careful 
that the new type satisfies all of the properties/invariants presumed 
by the rest of the system.  Clearly it is not possible to satisfy
all possible properties imaginable, for example the time or space
requirements of two types (and their associated operatios) will 
almost never be identical.  If time/space is critical to the
correct operation of the system (e.g. in a real-time embedded system),
then you must enumerate the requirements, and verify them for each
type in the set.  

Just saying "substitutability" doesn't really say anything, IMHO.
The real issue is establishing a set of "class-wide" requirements,
and then verifying them each time a new type is added to the set of
types within the class (hierarchy).

Eiffel tries to support this effort through class invariants, but
I believe it gets tripped up a bit by the conflict between establishing
useful invariants for a specific type/class in the class
hierarchy, which might want to be quite "tight" so as to catch as
many errors as possible, and the appropriate invariants for the 
entire class hierarchy, which want to be as "loose" as possible 
to ensure flexibility of extension.  There seems to be
a need to have two separate kinds of invariants -- those that apply to
an individual type/class, and a separate set that get "inherited",
and that apply throughout the class hierarchy.

:   Richard Riehle

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA