home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2504 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  3.7 KB

  1. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!destroyer!ubc-cs!uw-beaver!fluke!ssc-vax!dano
  2. From: dano@ssc-vax (Dan Olson)
  3. Newsgroups: comp.lang.ada
  4. Subject: Re: MI last time
  5. Message-ID: <5527@ssc-bee.ssc-vax.boeing.com>
  6. Date: 31 Aug 92 16:39:33 GMT
  7. References: <9208211316.AA12657@efftoo.boeing.com>
  8. Sender: news@ssc-vax.boeing.com
  9. Reply-To: dano@ssc-vax.boeing.com (Dan Olson)
  10. Organization: Boeing Aerospace & Electronics
  11. Lines: 71
  12.  
  13. Let me see if I can give some feeling on when to use multiple
  14. inheritance.  The information here is all based on experience in our
  15. s/w group and not just something read in a book.
  16.  
  17. MI is a concept that works very well when you have a collection of
  18. similar classes with various options.  Each option is represented by a
  19. "mixin class" that can be combined in nearly any way you like to get
  20. just the behavior desired.  In this way, the MI-able classes are like
  21. a toolkit.
  22.  
  23. As earlier noted, the Symbolics tv:window set of classes is a rather
  24. large scale example of where MI works well.  Other examples that I
  25. have worked with are a neural network class library that has various
  26. neural net behaviors as individual "mixins" and a collection class
  27. library that has different options as mixins such as:
  28.  
  29.   storage method: array, linked_list
  30.   memory type: physical, disk
  31.   behavior: unique elements (set), non_unique elements
  32.   key location: hash_table, linear_search, btree
  33.   sequence behavior: queue, stack, heap
  34.  
  35. For the collection class set example, if one used single inheritance
  36. and wanted to get most combinations of options it would require either
  37. a few really fat classes that had multiple options in them, or it
  38. would require code to be duplicated and a huge tree of classes.
  39.  
  40. With MI, you can just select the options you want and create a new
  41. class from them.  New options can be added later without modifying any
  42. of the existing classes.
  43.  
  44.  
  45. -- Why MI might not work --
  46.  
  47. Prob #1: One of the problems I have run into with MI is that of the OO
  48. languages I am familiar with (Lisp Flavors, Smalltalk (a little), and
  49. C++), only Flavors provides the facilities to easily do MI (at least
  50. in my experience).  In Flavors, you can combine mixins (I get the term
  51. "mixin" from Flavors) into a new class with very little or no glue
  52. code to decide how the mixin class methods get called.  In C++, this
  53. isn't the case (ADA 9x I am unfamiliar with it).  In C++ you must
  54. write new methods that decide what order to call the inherited
  55. methods.  In Flavors this usually isn't a problem since it provides
  56. what are called "method combinations" (ex. whoppers, :after, :before,
  57. :and, :or, :progn, etc) methods) which allow multiple inherited
  58. classes to all operate on the same message without the newly defined
  59. class needing any extra support code.
  60.  
  61. Rule #1: Creating a new class from a set of mixins should be as
  62. easy as just specifying the mixin names.
  63.  
  64.  
  65. Prob #2: Trying to design a set of classes from scratch that use MI is
  66. very difficult (for me at least).  You might start the design of a
  67. toolkit and end up with just a few variations that could have been
  68. done much more simply without MI.
  69.  
  70. Rule #2: Forget about MI during the initial design.  As the class tree
  71. grows and you begin to find yourself with many little variations, or
  72. the same basic ideas repeated, then a MI solution might be in store.
  73.  
  74. Rule #3: For that matter, forget about inheritance during the initial
  75. design and build classes as a forest instead of the big oak tree.
  76. Better inheritance schemes will become obvious in early prototypes of
  77. your design.
  78.  
  79. -- 
  80. dano  [] UUCP:      ..!uw-beaver!ssc-vax!dano
  81.       [] Internet:  dano@ssc-vax.boeing.com
  82. "Once the game is over, the king and the pawn go back in the same box."
  83. - Italian Proverb (I think)
  84.