From: Michael Campbell <michael_s_campbell@...>
Date: 2003-04-05T00:05:25+09:00
Subject: Re: To inherit or to include? That is the question.

> I've been poking around the mailing list looking for
> some insight into using inheritance vs module include.
> It seems like every time I have a good idea for some
> class, I wrangle with this question.

...

> I cannot see that the two behave that differently.
> I'm sure there are some differences. Maybe someone
> can help me enumerate them.
> 
> Ideally, I would like some set of guidelines to help
> me make a choice between these two.
> 
> Right now, it's fuzzy to me which one I should use.


The OO hardcore will tell you to differentiate not based on
behavioral differences, but focus on the "what is" question.

If MyApp "ISA" AppMaker, then inherit.  If it can do everything an
AppMaker can do (and all those things make sense), inheritance is the
better choice.

If, OTOH, MyApp ! "ISA" AppMaker, but simply needs some of its
behavior, or genuinely in your object model, contains an AppMaker,
then aggregation is the way to go.  

If neither work quite right, then maybe your object model is a bit
muddy.

However, if your AppMaker is a "bundle" of behavior and is supposed
to be mixed in and is to be used as part of the
behavior/implementation hierarchy rather than be a piece of the type
hierarchy, then the include/'require' solution makes sense.  (This
seems to me closer to aggregation than inheritance, but not quite, as
historically aggregation would allow you to "slim" the aggregatee's
available methods by delegating to it just the methods you want to
expose, where require gets you basically everything, much like
inheritance would.)

That's not necessarily the most pragmatic answer.  ["not necessarily
in ruby" anecdotes follow] Many people I've seen will inherit simply
to "get" all the base class' functionality, when the subclass ! "ISA"
base, just for convenience.  I've seen that bite backsides a lot too.

Too, in C++, a popular pastime was to factor common functionality
into a base class, simply because with C++'s multiple inheritance,
you could.  Always seemed kludgy to me.

But, that is sometimes pragmatic, and for small programs, might save
coding time and be perfectly understandable.  That distinction is, of
course, left as an exercise to the reader.

When in doubt, *I* tend to go the OO purist route.  I can always
change later, but I find that I have to refactor less when I do this.
 YMMV, of course.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com