Xref: utzoo comp.lang.c++:3337 comp.lang.eiffel:190 comp.lang.smalltalk:1079
Path: utzoo!attcan!uunet!mitel!sce!object!kain
From: kain@object.UUCP (Kai Ng)
Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk
Subject: Re: Use of inheritance for classification?
Keywords: metrics, oop
Message-ID: <6110@object.UUCP>
Date: 15 May 89 18:14:20 GMT
References: <30582@apple.Apple.COM>
Reply-To: kain@cognos.UUCP (Kai Ng)
Followup-To: comp.lang.c++
Organization: Cognos Inc., Ottawa, Canada
Lines: 95

In article <30582@apple.Apple.COM> kmcentee@Apple.COM (Kevin McEntee) writes:
>
>Meyer's Object Oriented Software Construction recommends that subclassing
>should take place only in the context of the is-a relationship.
>
>    e.g.  Every dog is a mammal.
>
>This seems to imply that inheritance is first a classification scheme and 
>only second a code sharing mechanism.  
>
>What are your thoughts on this?  Can code sharing outside of the natural 
>taxonomy of the problem space happen gracefully?
>

Dr. Meyer's "is-a" rule provides an easy to understand rule of thumb for
subclassing. Since object oriented programming has only emerged, even in
the academic world, for a relatively short period of time, programmers at
large in the production world are admittedly not well prepared to take on
such paradigm. That is the reason why the questions like

    "When should I subclass ?"
    "From which class I should inherit from ?"
    "Is it appropriate to add such a feature (method) to the heir class(es) ?"
    "Is it worthy to introduce a deferred (abstract) class in between ?"
    ....

are heard many many times over.

An important advantage of OOP, other than the familiar facilitating code
re-use, is good understandability which is achieved via some OOP conventions
and practices such as good naming, peronalizing (objectizing) objects and
rules like "is-a", etc. Although it is arguable whether integrating common
sense, like a dog is a mammal, with inheritance structure has too much
restriction or not, it is not questionable with the aid of such kind of
common sense, the characteristics of an object can be perceived better.

It is not uncommon programmers do not trust each other's code; and the
severity tends to be exponential inversely proportional to the degree
they understand the code. Hence don't feel supprised if you find a Car
object is more than 4-wheel drive.

My point is understandability encourages code re-use. Removing the natural
taxonomy inevitably, I believe, will remove the power of common sense.
You can draw your own conclusion then.

Even if you view inheritance as a classification scheme is not bad; most
software libraries classify various modules in some manner anyway.

Although I feel using the concept of generalization v.s. specialization
is a more suitable rule for subclassing, I always attempt not to break the
"is-a" rule.

The "is-a" rule is almost perfect in any single inheritance environment,
nevertheless it does has its short falls in a true mulitple inheritance
environment like Eiffel. The case is worse on the hand of a good OO programmer
who always manage to re-use more classes, i.e. inherit from more classes at
once. The problem is self-explained in the following example.

    CLASS SmallInteger
        -- General purpose small integer.

    INHERIT
        MachineConstants;
        Number

    ...
    END -- Class SmallInteger

The "is-a" rule is ok with Number-SmallInteger whereas it is not appliable
at all for MachineConstants-SmallInteger. In our group, we introduce a
keyword in the form of comment to clarify this.

    INHERIT
        -- Use --
        MachineConstants;

        -- Inherit --
        Number
    ...

If the inheritance status is USE, no feature is allowed to be exported.
It would be nice if USE is a real Eiffel keyword and exporting is enforced
by the compiler itself.







-- 
Kai Ng                 P.O. Box 9707         UUCP: uunet!mitel!sce!cognos!kain
Cognos Incorporated    3755 Riverside Dr.
(613) 738-1440         Ottawa, Ontario,
 ext. 6114             CANADA  K1G 3Z4