C++ Interface Classes - An Introduction

Class hierarchies that have run-time polymorphism as one of their prominent characteristics are a common design feature in C++ programs, and with good design, it should not be necessary for users of a class to be concerned with its implementation details. One of the mechanisms for achieving this objective is the separation of a class's interface from its implementation. Some programming languages, e.g. Java, have a mechanism available in the language for doing this. In Java, an interface can contain only method signatures. In C++ however, there is no such first class language feature, and the mechanisms already in the language must be used to emulate interfaces as best as can be achieved. To this end, an interface class is a class used to hoist the polymorphic interface - i.e. pure virtual function declarations - into a base class. The programmer using a class hierarchy can then do so via a base class that communicates only the interface of classes in the hierarchy.

The much used shape hierarchy example serves well here. Let's assume for the sake of illustration, that we have two kinds of shape: arc and line. The hierarchy therefore, contains three abstractions: the arc and line concrete classes, and the generalisation shape. From now on, I'll talk mainly about shape and line only - the latter serving as an illustration of an implementation. These two classes, in fragment form, look like this:

class shape {
public:
  virtual ~shape();
  virtual void move_x(distance x) = 0;
  virtual void move_y(distance y) = 0;
  virtual void rotate(angle rotation) = 0;
  //...
};

class line : public shape {
public:
  virtual ~line();
  virtual void move_x(distance x);
  virtual void move_y(distance y);
  virtual void rotate(angle rotation);
private:
  point end_point_1, end_point_2;
  //...
};

The shape abstraction is expressed here as an interface class - it contains nothing but pure virtual function declarations. This is as close as we can get in C++ to expressing an interface. Adding to the terminology, classes such as line (and arc) are known as implementation classes.

Now let's assume this hierarchy is to be used in a two dimensional drawing package. It seems reasonable to suggest that in this package, drawing may be another useful abstraction. drawing could be expressed as an interface class, like in this fragment:

class drawing {
public:
  virtual ~drawing();
  virtual void add(shape* additional_shape)
                                          = 0;
  //...
};

Besides the virtual destructor, only one member function of drawing - the add() virtual function - is shown. Note that drawing does not collaborate with any implementation of shape, but only with the interface class shape. This is sometimes known as abstract coupling - drawing can talk to any class that supports the shape interface.

Having explained the technique of hoisting a class's interface, I need to explain why developers should be interested in doing this. There are three points:

Returning to the first point above for a moment, there is a way by which we can strengthen the logical separation further: we can make shape's implementation classes into implementation only classes. This means that in the implementation classes, all the virtual member functions are made private, leaving only their constructors publicly accessible. The line class then looks like this:

class line : public shape {
public:
  line(point end_point_1, point end_point_2);
  //...
private:
  virtual ~line();
  virtual void move_x(distance x);
  virtual void move_y(distance y);
  virtual void rotate(angle rotation);
  //...
};

Now, the only thing users can do with line is create instances of it. All usage must be via its interface - i.e. shape, thus enforcing a stronger interface/implementation separation. Before leaving this topic, it is important to get something straight: the point of enforcing the interface/implementation separation is not to tell users what to do. Rather, the objective is to underpin the logical separation - the code now explains that the key abstraction is shape, and that line serves to provide an implementation of shape.

As a general design principle, all classes should have responsibilities that represent a primary design role played by the class. However, sometimes a class must also express functionality representing responsibilities that fall outside its primary design role. In such cases, the need for partitioning of this functionality is pressing, and interface classes have a part to play.

A class that expresses this kind of extra functionality is called a mixin. For example, it is easy to imagine there might be a requirement to store and retrieve the state of shape objects. However, storage and retrieval functionality is not a responsibility of shape in the application domain model. Therefore, a feasible design is as follows:

class serialisable {
public:
  virtual void load(istream& in) = 0;
  virtual void save(ostream& out) = 0;
protected:
  ~serialisable();
};

class shape : public serialisable {
public:
  virtual ~shape();
  virtual void move_x(distance x) = 0;
  virtual void move_y(distance y) = 0;
  virtual void rotate(angle rotation) = 0;
  // No declarations of load() or save() in
  // this class
  // ...
};

class line : public shape {
public:
  line(point end_point_1, point end_point_2);
  //...
private:
  virtual ~line();
  virtual void move_x(distance x);
  virtual void move_y(distance y);
  virtual void rotate(angle rotation);
  virtual void load(istream& in);
  virtual void save(ostream& out);
  //...
};

This approach is intrusive to a degree because serialisable's virtual member functions must be declared in line's interface. However, at least there is a separation in that serialisable is kept separate from the crucial shape abstraction.

Note that serialisable does not have a public virtual destructor - its destructor is protected and non-virtual. It is not intended that pointers to serialisable are held and passed around in a program - i.e. it is not a usage type, that's the role of the shape class. Making the destructor non-virtual and not publicly accessible allows the code to state this explicitly, without recourse to any further documentation.

Often mixin functionality is added to a class using multiple inheritance. Here there is an analogy with Java, in which there is direct language support for interfaces. In Java, a class can inherit from one other class, but can implement as many interfaces as desired. The same thing can be emulated in C++ using interface classes, but in C++ there is an added twist - C++ has private inheritance to offer. This approach comes in handy particularly when the usage type is outside the control of the programmer - for example, because it is part of a third party API. For example, consider a small framework where notifications are sent out by objects of type notifier, and received by classes supporting an interface defined by notifiable. The two interface classes (or fragment of, in the case of notifier) are defined as follows:

class notifiable {
public:
  virtual void update() = 0;
protected:
  ~notifiable();
};
class notifier {
public:
  virtual void register_client(notifiable* o)
                                          = 0;
  // ...
};

Now consider using a GUI toolkit that provides a base class called window, from which all window classes are to be derived. The programmer wishes to write a class called my_window that receives notifications from objects of type notifier - such a class could look like this:

class my_window : public window,
                  private notifiable {
public:
  void register_for_notifications(
                                notifier& n) {
    n.register_client(this);
  }
  // ...
};

Using private inheritance has rendered the notifiable interface inaccessible to clients, but allows my_window use of it, because like anything else that's private to my_window, its private base classes are accessible in its member functions. This approach helps to strengthen the separation of concerns which the use of mixin functionality seeks to promote.

The fact that we have to consider emulation issues at all is owing to the fact that interfaces are being emulated rather than being a first class language feature - all part of the fun of using C++! I think there are issues in two areas, i.e. those concerned with:

class shape {
public:
  virtual ~shape();
  virtual void move_x(distance x) = 0;
  virtual void move_y(distance y) = 0;
  virtual void rotate(angle rotation) = 0;
  // other virtual function declarations...
};

class shape {
public:
  // ...
private:
  shape& operator=(const shape&);
};

class line : public shape {
public:
  line(int in_x1, int in_y1,
       int in_x2, int in_y2)
    : x1(in_x1), y1(in_y1),
      x2(in_x2), y2(in_y2) {}
  // ...
private:
  int x1, y1, x2, y2;
};

class shape_impl : public shape {
private:
  virtual ~shape_impl() = 0;
  virtual void move_x(distance x);
  virtual void move_y(distance y);
  virtual void rotate(angle rotation);
  //...
protected:
  shape_impl();
  shape_impl(
          const rectangle& initial_proximity);
  //...
private:
  rectangle proximity;
  // ... 
};

class line : public shape_impl {
public:
  line(int in_x1, int in_y1,
       int in_x2, int in_y2)
    : x1(in_x1), y1(in_y1),
      x2(in_x2), y2(in_y2) {}
  // ...
private:
  int x1, y1, x2, y2;
};

class line : public shape {
public:
  line(int in_x1, int in_y1,
       int in_x2, int in_y2)
    : shape(), x1(in_x1), y1(in_y1),
      x2(in_x2), y2(in_y2) {}
  // ...
};

Interface classes are fundamental to programming with run time polymorphism in C++. Despite this, I'm all too frequently surprised by how little they are known about by the C++ programmers out there.

This article doesn't cover everything: for example, the use of virtual inheritance when deriving from mixins is something I hope to get around to covering in a future article. However, I hope this article serves as a reasonable introduction.

Many thanks to Phil Bass, Thaddaeus Frogley and Alan Griffiths for their feedback.