16.2 ISSUES THAT ARISE WITH REPEATED INHERITANCE

16.2 ISSUES THAT ARISE WITH REPEATED INHERITANCE

The most complicating issues that arise with MI have to do with what is known as repeated inheritance. Repeated inheritance takes place when a derived class inherits the same members of some base class through two different paths in a class hierarchy. To bring these issues into focus, consider the class hierarchy of Figure 16.5. The classes Manager and SalesPerson are both derived from the base class Employee. And the class SalesManager is derived from both Manager and SalesPerson. We have intentionally left unspecified the data members and the member functions in the final derived-class SalesManager, as the following discussion bears directly on their specification.

Figure 16.5

When a derived class can inherit members through multiple paths and when the different paths have an upstream class in common, the following issues become immediately relevant:

1. The Problem of Duplicate Construction of Common-Base Subobject:

   Recall from Chapter 15 that when the constructor of a derived class is invoked, the derived-class object so constructed has built inside it a base-class subobject.

   This is represented by Figure 16.6, which was also shown earlier in Chapter 15. That implies that, unless precautions are taken, when a constructor for SalesManager is invoked, we would end up with two different versions of the Employee slice in the constructed object, as illustrated by Figure 16.7. But that's not what we want. How do we prevent the formation of duplicate common-base subobjects in a derived-class object?

   
   Figure 16.6

   
   Figure 16.7

2. The Name-Conflict Problem for Member Functions:

   Suppose two member functions of the same signature but different implementations are inherited by the SalesManager class from the two different inheritance paths shown. If these member functions are not overridden in the SalesManager class, we can end up with an ill-formed program. This could, for example, be the case with the print() member function that is listed originally as a member of the class Employee. Let's say this function is modified by each class between Employee and SalesManager. If for some reason, this modified function is not overridden in SalesManager but yet invoked on an object of type SalesManager, you would have a compile-time ambiguity.

3. The Name-Conflict Problem for Data Members:

   The class SalesManager inherits two different data members with the same name—department—one each from the two superclasses Manager and SalesPerson. These two data members, although possessing the same name, possess different meanings for the derived class SalesManager because a SalesManager could conceivably have two different ‘department’ attributes associated with him or her. Such an individual could belong to a particular department of the corporation and, at the same time, be in charge of a particular unit of the sales organization which could also be referred to as a department. So how does one make sure that despite the same name—department—each data member gets the correct value when we construct an object of type SalesManager?

The next three sections will address each of the three problems listed above.