Interface and Implementation Inheritance

Inheritance Series Part 1

Recently while working on a problem, I ran into an issue with multiple-inheritance. While the problem itself was due to a compiler bug, it made me think about the virtues and vices of inheritance. Here, I am logging some of my current thoughts.

It seems that in object oriented paradigm, inheritance has realy two broad based uses

1. Polymorphism
2. Code Re-use

Polymorphism

Inheritance is at the heart of polymorphism and is one of the stated missions in object orientation. Though this is not the only way of achieving this (as in smalltalk), its use along with late binding provides for a very elegant solution. In this use case there are basically two points to be noted -

1. Means to specify the contract which the outside world will use - Interface Specification
2. Means to implement and stagger the implementation - which is obviously supported by inheritance. Single inheritance hierarchy scheme is more than sufficient to stagger the implementation from a generalized version to more specific versions

In other words what we are really doing is that we are inheriting the interface for the purpose of implementation and specialization and this concept is also called Interface Inheritance. Specialization is not implementation inheritance as we are not inheriting the implementation, but overriding it.

Code Re-use

Another use of inheritance and this is my current object of curiosity is Implementation Inheritance. This concept is generally considered a taboo and languages such as Java have banished this all together. C++ on the other hand provides even means to achieve this.

The idea of implementation inheritance is to use mix-in classes to inherit so that the derived classes can inherit the functionality provided by the mixed in class to achive its implementation without trying to expose the interface of the mixed in class. This fact is pretty important.

Lets consider a simple situation where multiple inheritance could be useful. Consider the case code snippet as shown below -

class ListImpl
{
public:
  void add(const Element&);
  void add(const Element&, int pos)
  Element& remove(int pos);
  Element& operator[](int pos);
};

class Stack
{
public:
  virtual void push(const Element&) = 0;
  virtual Element& pop() = 0;
}

class StackImpl :
  : public Stack // inherit the interface
  : protected ListImpl // part of implementation
{
public:
  void push(const Element&);
  Element& pop();
}

In the above example, the StackImpl inherits from the Stack ABC to inherit its interface which will be used by its clients. This is typical and what we normally understand. However, the inheritance of ListImpl is part of the stack implementation and is not part its supported and exposed interface and hence is Implementation Inheritance. C++ provides a nice way to hide the implementation inheritance from the users by letting the sub class inherit either privately or protectedly. Had it inherited publically, then the List interface would also have been part of the exposed interface of StackImpl class and this is not what we want.

This is not the only design choice available for Stack implementors. We could have also used Composition relationship between StackImpl and ListImpl class. This would have been a great way and possibly the best way, but if StackImpl needed to access something internal to ListImpl (Probably StackImpl and ListImpl are implemented by the same developer and StackImpl needs to access something internal in ListImpl for the sake of performance), then the only elegant way would have been to inherit it, otherwise, we would have had to expose ListImpl internals.