C++ Core Guidelines: Class Hierarchies

Let's talk in this post about rules for class hierarchies in general and in particular. The C++ core guidelines have about thirty rules; therefore, I have a lot to discuss.

First, what is a class hierarchy? The C++ core guidelines give a clear answer. Let me rephrase it. A class hierarchy represents a set of hierarchically organized concepts. Base classes typically act as interfaces. They are two uses for interfaces. One is called implementation inheritance, and the other is interface inheritance.

The first three lines are more general, or to say it differently: they summarize the more detailed rules.

Class hierarchy rule summary:

• C.120: Use class hierarchies to represent concepts with inherent hierarchical structure (only)
• C.121: If a base class is used as an interface, make it a pure abstract class
• C.122: Use abstract classes as interfaces when complete separation of interface and implementation is needed

C.120: Use class hierarchies to represent concepts with inherent hierarchical structure (only)

This is quite obvious. You should use a hierarchy if you model something in the code with an inherently hierarchical structure. The easiest way to reason about my code is if I have a natural match between the code and the world.

For example, I had to model a complex system. This system was a family of defibrillators that consisted of a lot of subsystems. For example, one subsystem was the user interface. The requirement was that the defibrillators should use different user interfaces such as a keyboard, a touch screen, or a few buttons. This system of subsystems was inherently hierarchical; therefore, I modeled it hierarchically. The great benefit was that the software was relatively easy to explain top-down because there was this natural match between the actual hardware and the software.

But, of course, the classic example of using a hierarchy in the design of a graphical user interface (GUI). This is the example the C++ core guidelines are using.

class DrawableUIElement {
public:
  virtual void render() const = 0;
// ...
};
class AbstractButton : public DrawableUIElement {
public:
  virtual void onClick() = 0;
// ...
};
class PushButton : public AbstractButton {
  virtual void render() const override;
  virtual void onClick() override;
// ...
};
class Checkbox : public AbstractButton {
// ...
};

If something is not inherently hierarchical, you should not model it hierarchically. Have a look here.

template<typename T>
class Container {
public:
    // list operations:
    virtual T& get() = 0;
    virtual void put(T&) = 0;
    virtual void insert(Position) = 0;
    // ...
    // vector operations:
    virtual T& operator[](int) = 0;
    virtual void sort() = 0;
    // ...
    // tree operations:
    virtual void balance() = 0;
    // ...
};

Why is the example terrible? You have only to read the comments. The class template Container consists of pure virtual functions for modeling a list, a vector, and a tree. If you use Container as an interface, you must implement three disjunct concepts.

C.121: If a base class is used as an interface, make it a pure abstract class

An abstract class is a class that has at least one pure virtual function. A pure virtual function (virtual void function() = 0 ) is a function that a derived class must implement if that class should not be abstract.

Only for completeness reasons. An abstract class can provide implementations of pure virtual functions. A derived class can, therefore, use these implementations.

Interfaces should usually consist of public pure virtual functions and a default/empty virtual destructor (virtual ~My_interface() = default).  If you don't follow the rule, something terrible may happen.

class Goof {
public:
// ...only pure virtual functions here ...
// no virtual destructor
};
class Derived : public Goof {
string s;
// ...
};
void use()
{
  unique_ptr<Goof> p {new Derived{"here we go"}};
  f(p.get()); // use Derived through the Goof interface 
} // leak

If p goes out of scope, it will be destroyed. But Goof has no virtual destructor; therefore, the destructor of Goof and not Derived is called. The harmful effect is that the destructor of the string s is not called.

C.122: Use abstract classes as interfaces when complete separation of interface and implementation is needed

Abstract classes are about the separation of interface and implementation. You can use a different implementation of Device in the following example during runtime because you only depend on the interface.

struct Device {
  virtual void write(span<const char> outbuf) = 0;
  virtual void read(span<char> inbuf) = 0;
};
class D1 : public Device {
// ... data ...
void write(span<const char> outbuf) override;
  void read(span<char> inbuf) override;
};
class D2 : public Device {
// ... different data ...
  void write(span<const char> outbuf) override;
  void read(span<char> inbuf) override;
};

In my seminars to design patterns, I often call this rule the meta-design pattern that is the base for a lot of the design patterns from the most influential software book: Design Patterns: Elements of Reusable Object-Oriented Software.

Designing rules for classes in a hierarchy summary:

Here are the more detailed rules in summary. The guidelines have 15 of them.

• C.126: An abstract class typically doesn’t need a constructor
• C.127: A class with a virtual function should have a virtual or protected destructor
• C.128: Virtual functions should specify exactly one of virtual, override, or final
• C.129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance
• C.130: Redefine or prohibit copying for a base class; prefer a virtual clone function instead
• C.131: Avoid trivial getters and setters
• C.132: Don’t make a function virtual without reason
• C.133: Avoid protected data
• C.134: Ensure all non-const data members have the same access level
• C.135: Use multiple inheritance to represent multiple distinct interfaces
• C.136: Use multiple inheritance to represent the union of implementation attributes
• C.137: Use virtual bases to avoid overly general base classes
• C.138: Create an overload set for a derived class and its bases with using
• C.139: Use final sparingly
• C.140: Do not provide different default arguments for a virtual function and an overrider

Today I write about the first three.

C.126: An abstract class typically doesn’t need a constructor

An abstract class typically has no data and needs no constructor to initialize them.

C.127: A class with a virtual function should have a virtual or protected destructor

A class with a virtual function is mainly used via a pointer or a reference to the base. Suppose you explicitly delete the derived class via a pointer, a reference to the base, or indirectly via a smart pointer. In that case, you want to be sure that the derived class's destructor is also called. This rule is similar to rule C.121, which discusses pure virtual functions.

Another way to solve the destruction issue is to have a protected and non-virtual base class destructor. This destructor guarantees you can not delete a derived object via a pointer or reference to the base.

C.128: Virtual functions should specify exactly one of virtual, override, or final

 In C++11, we have three keywords to deal with overriding.

• virtual: declares a function that can be overwritten in derived classes
• override: ensures that the function is virtual and overwrites a virtual function of a base class
• final: ensures that the function is virtual and cannot be overridden by a derived class

According to the guidelines, the rules for the usage of the three keywords are straightforward: "Use virtual only when declaring a new virtual function. Use override only when declaring an override. Use final only when declaring a final override."

struct Base{
    virtual void testGood(){}
    virtual void testBad(){}
};

struct Derived: Base{
    void testGood() final {}
    virtual void testBad() final override {}
};

int main(){
    Derived d;
}

The method testBad() in the class Derived has a lot of redundant information.

• You should only use final or override, if the function is virtual. Skip virtual:  void testBad() final override{}
• Using the keyword final without the virtual keyword is only valid if the function is already virtual; therefore, the function must override a virtual function of a base class. Skip override: void testBad() final {}

What's next?

The remaining twelve rules for class hierarchies are missing. My next post will close this gap.