home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!destroyer!ubc-cs!uw-beaver!fluke!ssc-vax!dano
- From: dano@ssc-vax (Dan Olson)
- Newsgroups: comp.lang.ada
- Subject: Re: MI last time
- Message-ID: <5527@ssc-bee.ssc-vax.boeing.com>
- Date: 31 Aug 92 16:39:33 GMT
- References: <9208211316.AA12657@efftoo.boeing.com>
- Sender: news@ssc-vax.boeing.com
- Reply-To: dano@ssc-vax.boeing.com (Dan Olson)
- Organization: Boeing Aerospace & Electronics
- Lines: 71
-
- 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)
-