Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!calmasd!wlp
From: wlp@calmasd.Prime.COM (Walter L. Peterson, Jr.)
Newsgroups: comp.lang.c++
Subject: Re: Use of inheritance for classification?
Message-ID: <327@calmasd.Prime.COM>
Date: 18 May 89 07:16:17 GMT
References: <30582@apple.Apple.COM> <10248@riks.csl.sony.JUNET> <329@odi.ODI.COM>
Organization: Prime-Calma, San Diego R&D, Object and Data Management Group
Lines: 131

In article <329@odi.ODI.COM>, dlw@valens.odi.com (Dan Weinreb) writes:
> 
> In just about all of the popular object-oriented languages, an object
> is a direct member of exactly one class.  So if you need special
> behavior for frisbee_catchers, then yes, you really do need a special
> class.  Of course, there's no hope here without multiple inheritance,
> since ability to catch frisbees is orthagonal to biological order.
> The graph would look like this:
> 
>   mammal   frisbee-catcher
>     |        |
>    dog       |
>     |        |
>     \        /
>    frisb-o-pup
> 
> This is perfectly consistent with the original claim.  A frisb-o-pup is a dog,
> a dog is a mammal, and a frisb-o-pup is a frisbee-catcher.


Most examples of multiple inheritance use some-what artificial
examples like the one above, and like the one above, most are
inappropriate for multiple inheritance.

The above example is mixing the paradigm upon which the hierarchy is
built. The "mammal-dog" hierarchy uses a taxonomic (in more than just
the biological sense) or "is-a" paradigm.  The "frisbee-catcher" is
not, in that paradigm, a thing that a dog (or other mammal) *IS*; it
is something that it *DOES*.  Part of the problem comes from the fact
that the class "frisbee-catcher" just seems to appear out of space.
If we think a bit about what the class "frisbee-catcher" is we can
flesh-out that part of the hierarchy and find a more appropriate way
of describing a frisbee catching dog.

Since the "mammal" hierarchy is an "is-a" hierarchy, we should have a
corresponding "is-a" hierarchy into which to fit the class
"frisbee-catcher".  Since catching frisbees is something that an
animal (we'll exclude robots for simplicity) does, we could call it a 
"skill".

This gives us two sub-hierarchies (both of which would be under some
super class such as "class" or "object") that are consistant in their
use of the hierarchical paradigm in that they are both "is-a" hierarchies.
Philosophical consistancy is not the only reason for doing this,
however. The simple example above is concerned with only one 'kind' of
dog; a "frisb-o-pup". But what happens when we add "sheep-dog",
"guide-dog", "guard-dog", etc. ?  The example in the original posting
would then require a distinct class for each of these, each multiply
inheriting not only from "dog" but from "shepherd", "guide", or "guard".
The resulting hierarchy graph would be such a mess that I don't even
want to think about trying to 'draw' it here. On the other hand, the
graphs of the two separate sub-hierarchies is clean and easy to
represent even in this medium.  The hierarchies (omitting the 'higher'
"class" or "object" classes) might look like this:


         mammal                                    skill
         ------                                    -----
           |                                         |
 --------------- ... ----              -------------------------- ... ----
 |         |     ...    |              |                  |       ...    |
cat       dog    ... aardvark       frisbee-catcher    shepherd   ...  guide
---       ---    ... --------       ---------------    --------   ...  -----


(For purists: Yes, there should be several levels of classes between
"mammal" and "dog", "cat", etc. ).


The connection between instances of class "dog" and instances of class
"skill" can easily be made by having an attribute (or field as some
say) for 'skill' in the definition of the class "dog".  This would
be an appropriate attribute for a dog, since we train dogs to have
such diverse skills. This raises a further problem with the example;
what do we do in the case of a multi-skilled dog? If a "sheep-dog" is
also a good "frisbee-catcher" do we create a "frisb-o-shep-o-dog"
class that inherits from "dog", "frisbee-catcher" and "shepherd" ?
I think not.  If we follow the alternative presented here, we can make
the skill attribute in class "dog" an aggregate such as a set or an array,
thus allowing an instance of class "dog" to not only have multiple skills,
but also allowing us to add skills as we train fido. The separation of
the two hierarchies also allows us to add new skill classes as needed.

This would allow the class "dog" to be defined as something like:

      DEFINE dog IS SUBCLASS OF mammal
      FIELDS
        name   : string
        skills : set OF skill
        .
        .
        .


(I KNOW that isn't C++ syntax (its DSM). The idea of what is being
done is what is important here, not the implementation details of
a specific language.)

The various skill classes would have fields appropriate to the
specific skill in question.

We can then create instances of "dog" for fido, rover, etc. creating
instances of the appropriate skill classes for each individual animal
and assigning appropriate values to the fields of the various instances.

Part of the problem with multiple inheritance is finding good cases
for its proper use.  Most of the examples that I have seen, including
the original posting above, have the common problem of being too
contrived and more appropriately solved by other means.  The only
example that I have seen that is both simple and from a familiar
problem domain to be used as a general example is from biological
taxonomy.  That example is the case of the true 'hybrid', such as a
mule. A mule, which is the offspring of a donkey and a horse, is
neither a "kind_of" horse nor is it a "kind-of" donkey; however, its
attributes are inherited ( in both the biological and object-oriented
sense ) from both "horse" and "donkey".  I have seen a few very good
examples of the appropriate use of multiple inheritance in CAD/CAM 
applications, but they are far too complex and are from too specialized
a problem domain to be useful for general examples.  

Inappropriate use of multiple inheritance can lead to convoluted,
overly complex object models that fail to do what they are meant to
do: map the problem domain into a program. Multiple inheritance is
a very useful thing to have available in an object-oriented language,
but it has a tremendous potential for abuse.

-- 
Walt Peterson.  Prime - Calma San Diego R&D (Object and Data Management Group)
"The opinions expressed here are my own and do not necessarily reflect those
Prime, Calma nor anyone else.
...{ucbvax|decvax}!sdcsvax!calmasd!wlp