Re: OOD, Ada, and Inheritance

[cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide@ucbvax.Berkeley.EDU (Bruce Weide)]

In article <1992Nov11.042043.9740@inmet.camb.inmet.com>
stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>We also believe that object-oriented approaches are a natural
>outgrowth of earlier work, in particular abstract-data-type (ADT)-oriented 
>approaches.  The big thing that OO brings is robust support
>for abstractions with *multiple* implementations.  Although the
>concept of multiple implementations of a given abstract data type
>was always discussed in academic circles, pre-OO languages with
>abstract data types rarely had good support for multiple implementations.
>

Good point about multiple implementations, but you don't need OO
mechanisms like inheritance to get multiple implementations.  For
example, the idea of multiple implementations is a central feature of
RESOLVE, which has no OO features except a special kind of
specification inheritance that has no bearing on multiple
implementations.  In fact, it seems Ada could be extended with (direct
language support for) multiple implementations, e.g., by permitting
separate naming of package specs and bodies and a way of binding them
together at instantiation time.  See a paper by M. Sitaraman in Proc.
ICCL, Apr 1992, for some ideas on how this could be done.  Ada-9X
doesn't seem to use this approach as I understand it.  Is there a
problem because of some subtle Ada eccentricity that I'm not seeing?

Or, by multiple implementations, do you mean to insist on run-time
selection among different implementations?  If so, what examples would
you (e.g., Ralph, or others holding this view) consider to be "good"
examples of the use of inheritance for this purpose; to be contrasted
with Rosen's examples, which are criticized as unrepresentative of
good OO practices?

>The only thing needed to ensure type safety
>is that the operation exists with the given parameter profile;
>the actual implementation of the operation need not be known (nor even
>exist) at compile-time of the client of the operation.
>
>In other words, the big step from "type-oriented" to "object-oriented"
>is not the concept of abstraction, but rather the concept that an
>object identifies its own implementation; its compile-time-known
>type only identifies its interface.

I'm sure I'm not telling anyone reading this anything they don't
already know, but there's more to the interface than the parameter
profile.  If you want to reason about how a client program is going to
behave when you call some operation, you'd better have some
implementation-independent specification of the abstract behavior of
that operation.  Put another way, correct software involves a lot more
than type-safety.  ALL the different implementations that might
actually be invoked by a call must have the same abstract behavior, or
you're going to have a hell of a time writing correct software (or at
least convincing yourself that it is correct).

What abstract explanation of this behavior are you going to use, then?
We could argue that this is not a language issue (at least not for an
implementation language like Ada), but someone has to think about this
problem before we can conclude which uses of inheritance are "good"
and which are "bad" from a software engineering perspective.


Cheers,
    -Bruce