Ruby User Group??

Thu Mar 21 11:20:02 2002

LOL!  This is great.  Funny and very educational.  About time we had some real meat discussion going on this list.  Keep it up, Rob and Carl.

Alan

On Thu, 21 Mar 2002 08:52:45 -0700 Rob Wehrli <rwehrli@azpower.com> wrote:
--<clip>--
 This is what I commonly talk about as being a Bird is not a 
Rock inheritance argument and, eventually, "avoidance" problem.

Birds use Rocks.  They (in real life) swallow little bits of rocks such 
that they get stuck in their gizzards and can subsequently grind up their 
food.  In your "behavoir" example where Form is a kind of an Array, a Bird 
is a kind of a Rock so that Bird can get at Rock's attributes and 
operations.  I think that we can clearly say that a Bird should not be a 
kind of a Rock.

The goal of OO is to model (at least more closely) real life "objects." 
 The design of an object hierarchy should be "sensible" in that you 
wouldn't find the definition of Bird inside of a Rock object and vice 
versa.  Where a Bird object requires a Rock "service provider" 
relationship, a simple interface and instantiation designation appears 
suitable for the task.  Generally, since Bird uses Rock, Bird instantiates 
(aggregation, also called composition) Rock(s) and uses the Rock's public 
interfaces to obtain Rock-offered services.  As good OO programmers, we 
don't make a Bird a kind of Rock so that we can easily have Rock's 
attributes and operations inside of Bird.

--<clip>--