Now that we know what a class is, and how to derive classes using inheritance, we’ll take a quick look at the slightly thorny issue of multiple inheritance. In the simplest terms, this is when a derived class has more than one base class. Theoretically a class may derive from any number of base classes, but in practice two or perhaps three base classes may be used.
One of the problems with using multiple inheritance is that different languages implement it differently. For instance, in C++ any class can derive all methods and data from parent classes, while Java on the other hand is very restrictive in how multiple inheritance can be applied. Ironically, the restrictions Java imposes mean that many designers and programmers find multiple inheritance is in fact more usable.
A common problem with multiple inheritance is the Diamond of Death effect. In this case, a class A derives from two parent classes B and C, but these two parent classes both derive from the same base class D. Because the new class A derives the entire tree structure of both parents, it will have inherited two copies of the superclass D. Though C++ provides the virtual base class construct to get around this issue, it is still a lurking danger for object oriented designs.
The confusion that can arise with multiple inheritance means that it needs to be treated with a little more respect than might be assumed. The bottom line is, don’t take it for granted!
As a simple example of multiple inheritance, think of our game characters. We can design our hierarchy a little differently to make use of multiple inheritance.
Here the playerCharacter class inherits from both class gameCharacter and class point. In this design, the currentLoc variable member of the gameCharacter class is no longer necessary, as the posX and posY attributes are now member variables of any gameCharacter objects created. This might seem to have great advantages, and it’s true that multiple inheritance can be extremely useful. However, the warning is clear – use the technique carefully. Remember that encapsulation is to a great extent the point of object oriented design, enabling secure, understandable and reusable code, so any method that has the potential to jeopordise these aims should always be used with a great deal of caution.