Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu!mrsvr.UUCP!pet3.uucp!hallett
From: hallett@pet3.uucp (Jeff Hallett x5163	)
Newsgroups: comp.object
Subject: Re: Inheritance IS NOT Delagation!!!!!
Message-ID: <1249@mrsvr.UUCP>
Date: 18 Oct 89 17:52:58 GMT
References: <125984@sun.Eng.Sun.COM> <17653@brunix.UUCP> <6219@jpl-devvax.JPL.NASA.GOV>
Sender: news@mrsvr.UUCP
Reply-To: hallett@gemed.ge.com (Jeffrey A. Hallett (414) 548-5163)
Organization: GE Medical Systems, Milwaukee,  WI
Lines: 59

In article <6219@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes:
>In article <17653@brunix.UUCP> sdm@norton.UUCP (Scott Meyers) writes:
>>In article <125984@sun.Eng.Sun.COM> grover%brahmand@Sun.COM (Vinod Grover) writes:
>>Lynn Stein, a graduate student here at Brown, proved that delegation and
>>inheritance are equivalent.  Hence, inheritance is not a "special case" of
>>delegation.  For the proof, see her paper in the OOPSLA '87 Proceedings:
>>"Delegation Is Inheritance."
>
>Using delagation, one builds a complex "object" through grouping
>several different small objects together.  Each small object maintains
>its own address space and thread.  The complex object is only
>conceptual.
>
>Delagation reflects reality better than inheritance:  your car does not
>inherit from door, tire, and engine: is is a composite made up of
>doors, tires, and an engine.  The fact that the window on the left door
>is open should have no bearing on the state of other windows or the
>fuel injection or tire pressure.

The relationships you  discuss can be expressed in  the form of a type
of aggragation   relations.  Aggragation  relations, in general, allow
for an  object to be composed of  other objects.   A relation  of this
type is generally  used  to express  things like  sets,  dictionaries,
bags, lists, stacks,  etc that are composed of  instances of the  same
class (or subclass).  However, we find it  useful to generalize to say
that  a class may    have   several aggragate  relations  to different
classes.  By using relations in this way, it is still possible for the
composite class to have properties and respond  to  messages as a unit
and then handle delegating method work to its components.

Are we all using the  same definition  of "delegation"?  Delegation of
responsibility (as we  have described it  here) is a natural result of
the object-oriented paradigm - let each object handle  the information
and properties given to members of its class.  Used this way, then car
does not  have to know specific about  car  doors - its simply queries
the car door when it needs to know something.

Clearly delegation in  this  sense cannot be equated  to  inheritance.
Delegation allows for specificity of  function and information whereas
inhertitance allows  for specificity  of form   - two related  but not
synonymous concepts.

>
>The average depth of inheritance in most systems is about 3.  The
>number of object types in many systems is very large, in the dozens to
>thousands.  Therefore, people tend to favor delagation over inheritance

Did  you  just pull  this  out  of  your hat?     I've never seen   an
inhertiance tree for a reasonably sized project with a depth less than
5.  Object number is large, as you  say, but for  a complex system, it
is  EASY to  have  specialized needs that drive the  tree to have long
branches. 


--
	     Jeffrey A. Hallett, PET Software Engineering
      GE Medical Systems, W641, PO Box 414, Milwaukee, WI  53201
	    (414) 548-5163 : EMAIL -  hallett@gemed.ge.com
     "Your logic was impeccable Captain. We are in grave danger."