![\"hierarchy](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/10\/hierarchy-73335_640.jpg\")
<\/p>\nLet’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.<\/p>\n
<\/p>\n
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.<\/p>\n
The first three lines are more general, or to say it differently: they summarize the more detailed rules.<\/p>\n
<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
class<\/span> DrawableUIElement<\/span> {\r\npublic:<\/span>\r\n virtual<\/span> void<\/span> render() const<\/span> =<\/span> 0<\/span>;\r\n\/\/ ...<\/span>\r\n};\r\nclass<\/span> AbstractButton<\/span> :<\/span> public<\/span> DrawableUIElement {\r\npublic:<\/span>\r\n virtual<\/span> void<\/span> onClick() =<\/span> 0<\/span>;\r\n\/\/ ...<\/span>\r\n};\r\nclass<\/span> PushButton<\/span> :<\/span> public<\/span> AbstractButton {\r\n virtual<\/span> void<\/span> render() const<\/span> override;\r\n virtual<\/span> void<\/span> onClick() override;\r\n\/\/ ...<\/span>\r\n};\r\nclass<\/span> Checkbox<\/span> :<\/span> public<\/span> AbstractButton {\r\n\/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
If something is not inherently hierarchical, you should not model it hierarchically. Have a look here.<\/p>\n
<\/p>\n
\ntemplate<\/span><<\/span>typename<\/span> T><\/span>\r\nclass<\/span> Container<\/span> {\r\npublic:<\/span>\r\n \/\/ list operations:<\/span>\r\n virtual<\/span> T&<\/span> get() =<\/span> 0<\/span>;\r\n virtual<\/span> void<\/span> put(T&<\/span>) =<\/span> 0<\/span>;\r\n virtual<\/span> void<\/span> insert(Position) =<\/span> 0<\/span>;\r\n \/\/ ...<\/span>\r\n \/\/ vector operations:<\/span>\r\n virtual<\/span> T&<\/span> operator<\/span>[](int<\/span>) =<\/span> 0<\/span>;\r\n virtual<\/span> void<\/span> sort() =<\/span> 0<\/span>;\r\n \/\/ ...<\/span>\r\n \/\/ tree operations:<\/span>\r\n virtual<\/span> void<\/span> balance() =<\/span> 0<\/span>;\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
Why is the example terrible? You have only to read the comments. The class template Container<\/span> 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.<\/p>\n<\/p>\nC.121: If a base class is used as an interface, make it a pure abstract class<\/a><\/h3>\nAn abstract class is a class that has at least one pure virtual function. A pure virtual function (virtual void function() = 0<\/span> ) is a function that a derived class must implement if that class should not be abstract.<\/p>\nOnly for completeness reasons. An abstract class can provide implementations of pure virtual functions. A derived class can, therefore, use these implementations.<\/p>\n
Interfaces should usually consist of public pure virtual functions and a default\/empty virtual destructor (virtual ~My_interface() = default<\/span>). If you don’t follow the rule, something terrible may happen.<\/p>\n\nclass<\/span> Goof<\/span> {\r\npublic:<\/span>\r\n\/\/ ...only pure virtual functions here ...<\/span>\r\n\/\/ no virtual destructor<\/span>\r\n};\r\nclass<\/span> Derived<\/span> :<\/span> public<\/span> Goof {\r\nstring s;\r\n\/\/ ...<\/span>\r\n};\r\nvoid<\/span> use<\/span>()\r\n{\r\n unique_ptr<<\/span>Goof><\/span> p {new<\/span> Derived{\"here we go\"<\/span>}};\r\n f(p.get()); \/\/ use Derived through the Goof interface <\/span>\r\n} \/\/ leak<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
If p goes out of scope, it will be destroyed. But Goof has no virtual destructor; therefore, the destructor of Goof <\/span>and not Derived <\/span>is called. The harmful effect is that the destructor of the string s is not called.<\/p>\nC.122: Use abstract classes as interfaces when complete separation of interface and implementation is needed<\/a><\/h3>\nAbstract classes are about the separation of interface and implementation. You can use a different implementation of Device<\/span> in the following example during runtime because you only depend on the interface.<\/p>\n\nstruct<\/span> Device {\r\n virtual<\/span> void<\/span> write(span<<\/span>const<\/span> char<\/span>><\/span> outbuf) =<\/span> 0<\/span>;\r\n virtual<\/span> void<\/span> read(span<<\/span>char<\/span>><\/span> inbuf) =<\/span> 0<\/span>;\r\n};\r\nclass<\/span> D1<\/span> :<\/span> public<\/span> Device {\r\n\/\/ ... data ...<\/span>\r\nvoid<\/span> write(span<<\/span>const<\/span> char<\/span>><\/span> outbuf) override;\r\n void<\/span> read(span<<\/span>char<\/span>><\/span> inbuf) override;\r\n};\r\nclass<\/span> D2<\/span> :<\/span> public<\/span> Device {\r\n\/\/ ... different data ...<\/span>\r\n void<\/span> write(span<<\/span>const<\/span> char<\/span>><\/span> outbuf) override;\r\n void<\/span> read(span<<\/span>char<\/span>><\/span> inbuf) override;\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
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.<\/b><\/a><\/p>\nDesigning rules for classes in a hierarchy summary:<\/h2>\n
Here are the more detailed rules in summary. The guidelines have 15 of them.<\/p>\n
\n- C.126: An abstract class typically doesn\u2019t need a constructor<\/a><\/li>\n
- C.127: A class with a virtual function should have a virtual or protected destructor<\/a><\/li>\n
- C.128: Virtual functions should specify exactly one of
virtual<\/code>, override<\/code>, or final<\/code><\/a><\/li>\n- C.129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance<\/a><\/li>\n
- C.130: Redefine or prohibit copying for a base class; prefer a virtual
clone<\/code> function instead<\/a><\/li>\n- C.131: Avoid trivial getters and setters<\/a><\/li>\n
- C.132: Don\u2019t make a function
virtual<\/code> without reason<\/a><\/li>\n- C.133: Avoid
protected<\/code> data<\/a><\/li>\n- C.134: Ensure all non-
const<\/code> data members have the same access level<\/a><\/li>\n- C.135: Use multiple inheritance to represent multiple distinct interfaces<\/a><\/li>\n
- C.136: Use multiple inheritance to represent the union of implementation attributes<\/a><\/li>\n
- C.137: Use
virtual<\/code> bases to avoid overly general base classes<\/a><\/li>\n- C.138: Create an overload set for a derived class and its bases with
using<\/code><\/a><\/li>\n- C.139: Use
final<\/code> sparingly<\/a><\/li>\n- C.140: Do not provide different default arguments for a virtual function and an overrider<\/a><\/li>\n<\/ul>\n
Today I write about the first three.<\/p>\n
C.126: An abstract class typically doesn\u2019t need a constructor<\/a><\/h3>\nAn abstract class typically has no data and needs no constructor to initialize them.<\/p>\n
C.127: A class with a virtual function should have a virtual or protected destructor<\/a><\/h3>\nA 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.<\/p>\n
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.<\/p>\n
C.128: Virtual functions should specify exactly one of virtual<\/code>, override<\/code>, or final<\/code><\/a><\/h3>\n In C++11, we have three keywords to deal with overriding.<\/p>\n
\n- virtual<\/span><\/strong>: declares a function that can be overwritten in derived classes<\/li>\n
- override<\/span><\/strong>: ensures that the function is virtual and overwrites a virtual function of a base class<\/li>\n
- final:<\/strong><\/span> ensures that the function is virtual and cannot be overridden by a derived class<\/li>\n<\/ul>\n
According to the guidelines, the rules for the usage of the three keywords are straightforward: “Use virtual<\/code> only when declaring a new virtual function. Use override<\/code> only when declaring an override. Use final<\/code> only when declaring a final override.”<\/p>\n\nstruct<\/span> Base{\r\n virtual<\/span> void<\/span> testGood(){}\r\n virtual<\/span> void<\/span> testBad(){}\r\n};\r\n\r\nstruct<\/span> Derived:<\/span> Base{\r\n void<\/span> testGood() final {}\r\n virtual<\/span> void<\/span> testBad() final override {}\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n Derived d;\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
The method testBad<\/span>() in the class Derived<\/span> has a lot of redundant information.<\/p>\n\n- You should only use