Professional C__ - Marc Gregoire [122]
};
A more refined mechanism for dealing with the top class in a diamond-shaped hierarchy, virtual base classes, is explained at the end of this chapter.
Uses for Multiple Inheritance
At this point, you’re probably wondering why programmers would want to tackle multiple inheritance in their code. The most straightforward use case for multiple inheritance is to define a class of objects that is-a something and also is-a something else. As was said in Chapter 3, any real-world objects you find that follow this pattern are unlikely to translate well into code.
One of the most compelling and simple uses of multiple inheritance is for the implementation of mix-in classes. Mix-in classes are explained in Chapter 3. An example implementation using multiple inheritance is shown in Chapter 28.
Another reason that people sometimes use multiple inheritance is to model a component-based class. Chapter 3 gave the example of an airplane simulator. The Airplane class has an engine, a fuselage, controls, and other components. While the typical implementation of an Airplane class would make each of these components a separate data member, you could use multiple inheritance. The airplane class would inherit from engine, fuselage, and controls, in effect getting the behaviors and properties of all of its components. We recommend you stay away from this type of code because it confuses a clear has-a relationship with inheritance, which should be used for is-a relationships. The recommended solution is to have an Airplane class which contains data members of type Engine, Fuselage, and Controls.
INTERESTING AND OBSCURE INHERITANCE ISSUES
Extending a class opens up a variety of issues. What characteristics of the class can and cannot be changed? What does the mysterious virtual keyword really do? These questions, and many more, are answered in the following sections.
Changing the Overridden Method’s Characteristics
For the most part, the reason you override a method is to change its implementation. Sometimes, however, you may want to change other characteristics of the method.
Changing the Method Return Type
A good rule of thumb is to override a method with the exact method declaration, or method prototype, that the superclass uses. The implementation can change, but the prototype stays the same.
That does not have to be the case, however. In C++, an overriding method can change the return type as long as the original return type is a pointer or reference to a class, and the new return type is a pointer or reference to a descendent class. Such types are called covariant return types. This feature sometimes comes in handy when the superclass and subclass work with objects in a parallel hierarchy. That is, another group of classes that is tangential, but related, to the first class hierarchy.
For example, consider a hypothetical cherry orchard simulator. You might have two hierarchies of classes that model different real-world objects but are obviously related. The first is the Cherry chain. The base class, Cherry, has a subclass called BingCherry. Similarly, there is another chain of classes with a base class called CherryTree and a subclass called BingCherryTree. Figure 8-10 shows the two class chains.
FIGURE 8-10
Now assume that the CherryTree class has a method called pick() that will retrieve a single cherry from the tree:
Cherry* CherryTree::pick()
{
return new Cherry();
}
Code snippet from Cherry\CherryTree.h
In the BingCherryTree subclass, you may want to override this method. Perhaps Bing Cherries need to be polished when they are picked (bear with us on this one). Because a BingCherry is a Cherry, you could leave the method prototype as is and override the method as in the following example. The BingCherry pointer is automatically cast to a Cherry pointer.
Cherry* BingCherryTree::pick()
{
BingCherry* theCherry = new BingCherry();
theCherry->polish();
return theCherry;
}
The implementation above is perfectly fine and is probably the way that the authors would write it. However, because