From: dano@ssc-vax (Dan Olson)
Newsgroups: comp.lang.ada
Subject: Re: MI last time
Date: 31 Aug 92 16:39:33 GMT
Reply-To: dano@ssc-vax.boeing.com (Dan Olson)
Organization: Boeing Aerospace & Electronics

Let me see if I can give some feeling on when to use multiple
inheritance.  The information here is all based on experience in our
s/w group and not just something read in a book.

MI is a concept that works very well when you have a collection of
similar classes with various options.  Each option is represented by a
"mixin class" that can be combined in nearly any way you like to get
just the behavior desired.  In this way, the MI-able classes are like
a toolkit.

As earlier noted, the Symbolics tv:window set of classes is a rather
large scale example of where MI works well.  Other examples that I
have worked with are a neural network class library that has various
neural net behaviors as individual "mixins" and a collection class
library that has different options as mixins such as:

  storage method: array, linked_list
  memory type: physical, disk
  behavior: unique elements (set), non_unique elements
  key location: hash_table, linear_search, btree
  sequence behavior: queue, stack, heap

For the collection class set example, if one used single inheritance
and wanted to get most combinations of options it would require either
a few really fat classes that had multiple options in them, or it
would require code to be duplicated and a huge tree of classes.

With MI, you can just select the options you want and create a new
class from them.  New options can be added later without modifying any
of the existing classes.


-- Why MI might not work --

Prob #1: One of the problems I have run into with MI is that of the OO
languages I am familiar with (Lisp Flavors, Smalltalk (a little), and
C++), only Flavors provides the facilities to easily do MI (at least
in my experience).  In Flavors, you can combine mixins (I get the term
"mixin" from Flavors) into a new class with very little or no glue
code to decide how the mixin class methods get called.  In C++, this
isn't the case (ADA 9x I am unfamiliar with it).  In C++ you must
write new methods that decide what order to call the inherited
methods.  In Flavors this usually isn't a problem since it provides
what are called "method combinations" (ex. whoppers, :after, :before,
:and, :or, :progn, etc) methods) which allow multiple inherited
classes to all operate on the same message without the newly defined
class needing any extra support code.

Rule #1: Creating a new class from a set of mixins should be as
easy as just specifying the mixin names.


Prob #2: Trying to design a set of classes from scratch that use MI is
very difficult (for me at least).  You might start the design of a
toolkit and end up with just a few variations that could have been
done much more simply without MI.

Rule #2: Forget about MI during the initial design.  As the class tree
grows and you begin to find yourself with many little variations, or
the same basic ideas repeated, then a MI solution might be in store.

Rule #3: For that matter, forget about inheritance during the initial
design and build classes as a forest instead of the big oak tree.
Better inheritance schemes will become obvious in early prototypes of
your design.

-- 
dano  [] UUCP:      ..!uw-beaver!ssc-vax!dano
      [] Internet:  dano@ssc-vax.boeing.com
"Once the game is over, the king and the pawn go back in the same box."
- Italian Proverb (I think)
Newsgroups: comp.lang.ada