From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: O.M() versus M(O) notation
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sun, 16 Aug 1992 21:28:18 GMT

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>Then, wouldn't it be better to adopt a 'reusable, orthogonal' components
>for building a class rather than leaving bits of a monolithic definition
>missing?

>I tend to think the former results in cleaner, less misleading notation,
>and greater generality. As a rule, those notations in which the
>primitive construct is a monolithic interface/implementation/specification
>definition idiom tend to have bizarre rules and restrictions on how the
>idiom can be subsetted and how subset definitions can be merged.

First, I agree completely that it is a good idea to separate interface
from implementation and from specification.  There are times when you
want to be able to reuse one of them without reusing the other, and
combining them in the way that all the popular object-oriented languages
do makes it harder to reuse just the piece you need.  This results in
tricks like overriding an operation to make it generate an error
message, which Piercarlo complained about.  Separating interface from
implementation seems to be the trend in the design of object-oriented 
programming languages.  There are several research languages that follow 
this path, though the only language I know about that is expected to be 
widely used and that separates interface from implementation is the 
object-oriented Cobol proposal.  I'd love to be told of languages that
separate specification from implementation that I don't know about.

Note that languages like Smalltalk have only implementation; they don't
provide a separate interface or specification.  Only Eiffel provides
any sort of specification (pre and post conditions and class invariants)
in the language.

However, Piercarlo wrote those paragraphs in response to the following
remark of mine, which shows that I was not being clear.

>johnson> An abstract class is much more than just an interface
>johnson> specification.  It also includes part of the implementation of
>johnson> the class, but it has some 'holes' in it that subclasses must
>johnson> fill in.  It is really a reusable design for subclasses, not an
>johnson> interface specification.  Of course, in languages without
>johnson> separate interface specifications, people use abstract classes
>johnson> to make a separate entity in their program that is just
>johnson> interface.

The purpose of an abstract class is NOT supposed to be to represent
an interface.  An abstract class represents a skeleton for a class.
It is a class that is to be used ONLY by subclassing.  A subclass
designer creates a subclass by filling in the 'holes', i.e. by
"fleshing out" the skeleton.  It is true that C++ programmers will
create a class that is only interface, with no implementation at all,
but that is not the real purpose of an abstract class.  An abstract
class is implementation, not just interface.

An abstract class defines some "abstract" or "deferred" methods
whose interface is defined, but whose implementation is not.
It also defines some "template" methods that are defined in terms
of the abstract methods.  Subclasses must provide an implementation
of each of the abstract methods, and then they can use the template
methods that they inherit.  This is a very important and common
design technique in object-oriented systems.  It would be just as
useful if languages separated interface from implementations.

Ralph Johnson -- University of Illinois at Urbana-Champaign
Xref: sparky comp.object:3258 comp.lang.clos:662