Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!deccrl!news.crl.dec.com!decvax.dec.com!zinn!nuucp
From: mjv@objects.mv.com (Michael J. Vilot)
Newsgroups: comp.lang.c++
Subject: Re: Nonvirtual base classes in MI
Message-ID: <1159@zinn.MV.COM>
Date: 31 Jan 91 03:14:05 GMT
Sender: nuucp@zinn.MV.COM
Lines: 36

Scott Meyers asked for an example of using multiple inheritance without using
virtual base classes.  I used exactly this approach in the design of the C++
Booch Components library, to use mixin classes to achieve a couple of purposes.

First, let me point out that the Booch Components library has a ``forest'' 
architecture, and thus avoids the common base class arrangement that leads to
the complexities of using MI in that context.  Second, I used private and 
public base classes for different design purposes.

The first use I made of MI was to create ``concrete'' classes from abstract
base classes (ABCs).  These concrete classes had both the ABC and a base class
for representation.  With this arrangement, the library can provide alternate 
implementations of the ABC, each with different time/space complexity.  In this
case, the base class for representation is a second, private base class.

The second use I made of MI was to mix in specific behavior for Node classes in
the unbounded representations.  Some of the Booch Components are what we call
``polylithic'' structures.  That is, they can share their representation among
several objects.  Shared_Nodes are kinds of Nodes that mix in a Shared base
class.  This approach let me build the Shared class once (implementing reference
counting), and mix it in as needed.  The library also supports Managed 
components, which take over free list management from the global operators new
and delete.  A Managed_Node mixes in a base class Managed, which provides the
class-specific operators new and delete.  Again, I only had to build that 
mechanism once to use it in various places.

I found the result to be quite satisfactory.  It clearly represents the design
structure, and helps keep the large library fairly well organized.  I think the
key to this is the separation between ``type'' and class that Doug Lea and
Marshall Cline described in their paper ``An Object Oriented Graphical Design
Method that Distinguishes Types from Classes'' that they presented at the GOOSE
workshop at ECOOPSLA last October.

--
Mike Vilot,  ObjectWare Inc, Nashua NH
mjv@objects.mv.com  (UUCP:  ...!decvax!zinn!objects!mjv)