Multiple inheritance

Multiple inheritance is a fairly new feature in object-oriented languages, and it is easy to design a confusing class hierarchy that resembles a bowl of spaghetti. Here are some design guidelines useful for managing multiple inheritance.

Classes in the Taligent Application Environment are artificially partitioned into two categories: base classes that represent fundamental functional objects (like a car), and mixin classes that represent optional functionality (like power steering). To distinguish between the two, base class names begin with T, and mixin class names begin with M (see "Name conventions" on page 58). To control multiple inheritance:

A class may inherit from zero or one base classes, plus zero or more mixin classes. If a class does not inherit from a base class, it probably should be a mixin class (though not always, such as if it is at the root of a hierarchy).

A class that inherits from a base class is itself a base class; it can't be a mixin class. Mixin classes can only inherit from other mixin classes.

The net effect of these two guidelines is that base classes form a conventional, tree-structured inheritance hierarchy rather than an arbitrary acyclic graph. This makes the base class hierarchy much easier to understand. Mixins then become add-in options that do not fundamentally alter the inheritance hierarchy.

Like all guidelines, these are not meant to be hard and fast rules. You can and should use multiple inheritance in other ways as well if it makes sense. Remember, people are better at understanding regular structures than arbitrary directed acyclic graphs.

[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker