Xref: utzoo comp.lang.c++:3420 comp.lang.eiffel:205 comp.lang.smalltalk:1097
Path: utzoo!attcan!uunet!mcvax!kth!sunic!dkuug!iesd!kasper
From: kasper@iesd.dk (Kasper Osterbye)
Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk
Subject: Re: Use of inheritance for classification?
Keywords: sub-class, super-class
Message-ID: <1947@iesd.dk>
Date: 24 May 89 08:28:28 GMT
References: <30582@apple.Apple.COM> <6365@brunix.UUCP> <4369@watvlsi.waterloo.edu> <329@calmasd.Prime.COM>
Reply-To: kasper@iesd.dk (Kasper Osterbye)
Organization: Dept. of Comp. Sci., Aalborg University, Denmark
Lines: 77

Then here is my N cents of ideas for this discussion.

First I believe that inherritance are used for two things. It is
used for classification in descriptions of real world entities, eg.
the IS-A relation. This is an important use especially when seen
in connections to systems build around the JSD architecture, which
is also advocated by Meyer (though not so explicitly).
    JSD is Jackson System Development method, described in Michael
    Jackson, System Development, Prentice-Hall, 1983. Highly recommended!

Second inheritance is used for code-sharing (or behaviour-sharing
if that is a less upsetting word). This can be seen in Smalltalk
where Semaphore is a subclass of linked list.

My observation is that both of these views are important, but they
unfortunately get in the way of each other. I see some solutions
to this.

Solution number 1.

This example is along the lines of the frisbee-catching-brown-sheepdog.
In flavors they have a notion of mixin's. (I am not very familiar
with Flavours, and got the idea from elsewhere, but the word mixin
is good for this example). If we take a class car, we can write a
number of classes that describe various features that can be added
to cars. PowerSteering, Sunroof, CarStereo, automatic shift etc.

When I need a car, I make a subclass of car, MyCar. But in making
that subclass I can use anynumber of mixins I care for (and can pay
for). If I make a Car1 with stereo and a Car2 with Sunroof. If I
now want a car with both stereo and sunroof, I do not make a subclass
of Car1 and Car2, but rather a new subclass of Car, Car3 with the
stereo and sunroof mixins.

An other classical example of multiple inherritance is the window
example, where we have window, titlebars, scrollable windows and
boardered windows. Again, the titlebar, scrolling, and boarder can
be made features/mixins to be used in for concrete windows.

Now what are these secondary classes in the inherritance. In my examples
they do not represent the IS-A relation, but rather the HAS-PART
relation. They are used as aggregation rather than specialization.
Also a very good example is that it makes sence to inherrit from
the same mixin twice (or more), I might want to add two sunroofs
in my streched limosine. Or a person could have two programming jobs,
thus being a programmer twice.

Also these special classes like sunroof are not intended as stand
alone classes, and they can normally not be used as mixins for other
classes. (A horse or a bike with sunroof?). That is they are intended
to serve as PARTS.


Solution number 2.

One could considder a language where we had a specification of the
class in some higher level language. These specifications could be
organized in a hierarchy also, but not necessaly following the class
hierarchy. The hierarchy of the specifications could then be made
to follow the IS-A relation, as there is no need for code-sharing
in specifications. And the classes could be organiced in a code-sharing
hierarchy. I have not thought about this solution as much as the
other one.


For anyone interested, I am working on a paper of the first solution,
that I can send/mail (its in latex).

Regards,
    Kasper.


-- 
Kasper Osterbye                     Internet: iesd!kasper@uunet.uu.net
Institute for electronic systems    UUCP: ...!mcvax!iesd!kasper
Strandvejen 19, 9000 Aalborg
DENMARK. (W) +45 98 13 87 88-285  (H) +45 98 37 30 65