Xref: utzoo comp.lang.c++:3333 comp.lang.eiffel:189 comp.lang.smalltalk:1077
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!rutgers!att!ihlpl!jwd
From: jwd@ihlpl.ATT.COM (Davison)
Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk
Subject: Re: Use of inheritance for classification?
Keywords: metrics, oop
Message-ID: <10554@ihlpl.ATT.COM>
Date: 16 May 89 20:46:03 GMT
References: <30582@apple.Apple.COM>
Reply-To: jwd@ihlpl.UUCP (55413-Davison,J.W.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 48

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?
>                                     ^^^^^^^^^^

I'm glad you added that last word.  It seems to me there are
several non-taxonomic reasons one might use inheritance for
particular methods, but inheriting all methods from a class seems
to imply some sort of strong relationship between the classes.  If
not "is-a" perhaps "acts-like-a" or "impersonates."  I feel the
inheritance structures ought to have an epistemological basis of
some kind.  It seems to me that the work done in knowlege
representation systems is directly applicable to many questions
like this.  I recommend Ron Brachman's paper "I lied about the
Trees", AI Magazine, Vol 6, No 3, Fall, 1985, for instance.
Constantine's/Yourdon's ideas on coupling/cohesion in Structured
Design (Prentice Hall, 1979) also seems relevant, as do database
normalization ideas.

Inheritance for individual methods is often desired because there
is "one" thing that needs to be done, and it should be only
specified once, but it really doesn't "belong" at the point in the
inheritance chain where it has to be to be accessible to all
concerned classes.  In this case, delegation seems to be a better
solution, an instance variable holds an object of the "appropriate"
class, (the one that "ought" to own the method), and a local method
simply passes the message to that object. 

Perhaps multiple inheritance can provide an out, where one
inheritance path is "is-a" while another represents some other
relationship.  

The "gracefulness" seems to rely on something a bit stronger than
"coincidental coupling".

-- 
		Joe Davison
		ihlts!joed 
		IH 6N-424  x4920