Multiple Inheritance

All the classes you’ve seen so far have had only a single direct superclass. Common Lisp also supports multiple inheritance—a class can have multiple direct superclasses, inheriting applicable methods and slot specifiers from all of them.

Multiple inheritance doesn’t dramatically change any of the mechanisms of inheritance I’ve discussed so far—every user-defined class already has multiple superclasses since they all extend **STANDARD-OBJECT**, which extends **T**, and so have at least two superclasses. The wrinkle that multiple inheritance adds is that a class can have more than one direct superclass. This complicates the notion of class specificity that’s used both when building the effective methods for a generic function and when merging inherited slot specifiers.

That is, if classes could have only a single direct superclass, ordering classes by specificity would be trivial—a class and all its superclasses could be ordered in a straight line starting from the class itself, followed by its single direct superclass, followed by its direct superclass, all the way up to **T**. But when a class has multiple direct superclasses, those superclasses are typically not related to each other—indeed, if one was a subclass of another, you wouldn’t need to subclass both directly. In that case, the rule that subclasses are more specific than their superclasses isn’t enough to order all the superclasses. So Common Lisp uses a second rule that sorts unrelated superclasses according to the order they’re listed in the **DEFCLASS**‘s direct superclass list—classes earlier in the list are considered more specific than classes later in the list. This rule is admittedly somewhat arbitrary but does allow every class to have a linear class precedence list, which can be used to determine which superclasses should be considered more specific than others. Note, however, there’s no global ordering of classes—each class has its own class precedence list, and the same classes can appear in different orders in different classes’ class precedence lists.

To see how this works, let’s add a class to the banking app: money-market-account. A money market account combines the characteristics of a checking account and a savings account: a customer can write checks against it, but it also earns interest. You might define it like this:

(defclass money-market-account (checking-account savings-account) ())

The class precedence list for money-market-account will be as follows:

(money-market-account
 checking-account
 savings-account
 bank-account
 standard-object
 t)

Note how this list satisfies both rules: every class appears before all its superclasses, and checking-account and savings-account appear in the order specified in **DEFCLASS**.

This class defines no slots of its own but will inherit slots from both of its direct superclasses, including the slots they inherit from their superclasses. Likewise, any method that’s applicable to any class in the class precedence list will be applicable to a money-market-account object. Because all slot specifiers for the same slot are merged, it doesn’t matter that money-market-account inherits the same slot specifiers from bank-account twice. 12

Multiple inheritance is easiest to understand when the different superclasses provide completely independent slots and behaviors. For instance, money-market-account will inherit slots and behaviors for dealing with checks from checking-account and slots and behaviors for computing interest from savings-account. You don’t have to worry about the class precedence list for methods and slots inherited from only one superclass or another.

However, it’s also possible to inherit different methods for the same generic function from different superclasses. In that case, the class precedence list does come into play. For instance, suppose the banking application defined a generic function print-statement used to generate monthly statements. Presumably there would already be methods for print-statement specialized on both checking-account and savings-account. Both of these methods will be applicable to instances of money-market-account, but the one specialized on checking-account will be considered more specific than the one on savings-account because checking-account precedes savings-account in money-market-account‘s class precedence list.

Assuming the inherited methods are all primary methods and you haven’t defined any other methods, the method specialized on checking-account will be used if you invoke print-statement on money-market-account. However, that won’t necessarily give you the behavior you want since you probably want a money market account’s statement to contain elements of both a checking account and a savings account statement.

You can modify the behavior of print-statement for money-market-accounts in a couple ways. One straightforward way is to define a new primary method specialized on money-market-account. This gives you the most control over the new behavior but will probably require more new code than some other options I’ll discuss in a moment. The problem is that while you can use **CALL-NEXT-METHOD** to call “up” to the next most specific method, namely, the one specialized on checking-account, there’s no way to invoke a particular less-specific method, such as the one specialized on savings-account. Thus, if you want to be able to reuse the code that prints the savings-account part of the statement, you’ll need to break that code into a separate function, which you can then call directly from both the money-market-account and savings-account print-statement methods.

Another possibility is to write the primary methods of all three classes to call **CALL-NEXT-METHOD**. Then the method specialized on money-market-account will use **CALL-NEXT-METHOD** to invoke the method specialized on checking-account. When that method calls **CALL-NEXT-METHOD**, it will result in running the savings-account method since it will be the next most specific method according to money-market-account‘s class precedence list.

Of course, if you’re going to rely on a coding convention—that every method calls **CALL-NEXT-METHOD**--to ensure all the applicable methods run at some point, you should think about using auxiliary methods instead. In this case, instead of defining primary methods on print-statement for checking-account and savings-account, you can define those methods as :after methods, defining a single primary method on bank-account. Then, print-statement, called on a money-market-account, will print a basic account statement, output by the primary method specialized on bank-account, followed by details output by the :after methods specialized on savings-account and checking-account. And if you want to add details specific to money-market-accounts, you can define an :after method specialized on money-market-account, which will run last of all.

The advantage of using auxiliary methods is that it makes it quite clear which methods are primarily responsible for implementing the generic function and which ones are only contributing additional bits of functionality. The disadvantage is that you don’t get fine-grained control over the order in which the auxiliary methods run—if you wanted the checking-account part of the statement to print before the savings-account part, you’d have to change the order in which the money-market-account subclasses those classes. But that’s a fairly dramatic change that could affect other methods and inherited slots. In general, if you find yourself twiddling the order of the direct superclass list as a way of fine-tuning the behavior of specific methods, you probably need to step back and rethink your approach.

On the other hand, if you don’t care exactly what the order is but want it to be consistent across several generic functions, then using auxiliary methods may be just the thing. For example, if in addition to print-statement you have a print-detailed-statement generic function, you can implement both functions using :after methods on the various subclasses of bank-account, and the order of the parts of both a regular and a detailed statement will be the same.