![\"hierarchy\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/10\/hierarchy.png\")
<\/p>\nI needed three posts to present the 20 rules for class hierarchies in the C++ core guidelines. Here are the seven remaining rules.<\/p>\n
<\/p>\n
To get the great picture. These are all special rules for class hierarchies.<\/p>\n
<\/p>\n
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
Let’s continue with rule C.134. <\/code><\/a><\/p>\nC.134: Ensure all non-const<\/code> data members have the same access level<\/a><\/h2>\nThe previous rule C.133, stated that you should avoid protected data. This means all your non-const data members should be either public or private. An object can have data members that do not prescribe the object’s invariants. Non-const data members that do not prescribe the invariants of an object should be public. In contrast, non-const private data members are used for the object invariants. To remind you: a data member having an invariant cannot have all values of the underlying type.<\/p>\n
If you think about class design more generally, you will recognize two kinds of classes.<\/p>\n
\n- All public<\/strong>: classes with only public data members because the data members have no invariant. Honestly, you should use a struct.<\/li>\n
- All private<\/strong>: classes with only private or const data members that established the invariant.<\/li>\n<\/ul>\n
Based on this observation, all your non-const data members should be public or private.<\/p>\n
Imagine if you have a class with public and non-constant invariants. This means that you must maintain the data members’ invariance through the whole class hierarchy. This is quite error-prone because you can not easily control the invariants of your class. Or to say it differently. You break encapsulation.<\/p>\n<\/p>\n
C.135: Use multiple inheritance to represent multiple distinct interfaces<\/a><\/h2>\nIt is a good idea that your interfaces will only support one aspect of your design. What does that mean? A concrete class must implement all functions if you provide a pure interface consisting only of pure virtual functions. In particular, in the case of a too-rich interface, the class has to implement functions it doesn’t need or make no sense.<\/p>\n
Examples of two distinct interfaces are istream<\/span> and ostream<\/span> from the input and output streams library.<\/p>\n<\/p>\n
\nclass<\/span> iostream<\/span> :<\/span> public<\/span> istream, public<\/span> ostream { \/\/ very simplified<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
By combining both interfaces istream<\/span> for input operations and ostream<\/span> for output operations, we can quite easily create a new interface.<\/p>\nC.136: Use multiple inheritance to represent the union of implementation attributes, <\/a>C.137: Use virtual<\/code> bases to avoid overly general base classes<\/a><\/h2>\nBoth rules are pretty special. Therefore I will skip them. The guidelines said that C.137 is relatively seldom used and that C.138 is similar to C. 129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance.<\/a><\/p>\nC.138: Create an overload set for a derived class and its bases with using<\/code><\/a><\/h2>\nThis rule is quite apparent and holds for virtual and non-virtual functions. If you don’t use the using-declaration, member functions in the derived class hide the entire overload set. Sometimes this process is called shadowing. Breaking these rules is often quite confusing.<\/p>\n
An example from the guidelines makes this rule quite clear.<\/p>\n
<\/p>\n
\nclass<\/span> B<\/span> {\r\npublic:<\/span>\r\n virtual<\/span> int<\/span> f(int<\/span> i) { std::<\/span>cout <<<\/span> \"f(int): \"<\/span>; return<\/span> i; }\r\n virtual<\/span> double<\/span> f(double<\/span> d) { std::<\/span>cout <<<\/span> \"f(double): \"<\/span>; return<\/span> d; }\r\n};\r\nclass<\/span> D<\/span>:<\/span> public<\/span> B {\r\npublic:<\/span>\r\n int<\/span> f(int<\/span> i) override { std::<\/span>cout <<<\/span> \"f(int): \"<\/span>; return<\/span> i +<\/span> 1<\/span>; }\r\n};\r\nint<\/span> main<\/span>()\r\n{\r\n D d;\r\n std::<\/span>cout <<<\/span> d.f(2<\/span>) <<<\/span> '\\n'<\/span>; \/\/ prints \"f(int): 3\"<\/span>\r\n std::<\/span>cout <<<\/span> d.f(2.3<\/span>) <<<\/span> '\\n'<\/span>; \/\/ prints \"f(int): 3\"<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Look at the last line. d.f(2.3)<\/span> with a double<\/span> argument is called, but the int<\/span> overload of class D is used; therefore, a narrowing conversion from double<\/span> to int<\/span> happens. That is, most of the time, not the behavior you want. To use the double<\/span> overload of class B, you must introduce it in the scope of D.<\/p>\n <\/p>\n
<\/p>\n
\nclass<\/span> D<\/span>:<\/span> public<\/span> B {\r\npublic:<\/span>\r\n int<\/span> f(int<\/span> i) override { std::<\/span>cout <<<\/span> \"f(int): \"<\/span>; return<\/span> i +<\/span> 1<\/span>; }\r\n using<\/span> B::<\/span>f; \/\/ exposes f(double)<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
C.139: Use final<\/code> sparingly<\/a><\/h2>\n final<\/span> is a new feature with C++11. You can use it for a class or a virtual function.<\/p>\n\n- If you derive a class My_widge<\/span>t final from a class Widget,<\/span> you cannot further derive a class from My_widget.<\/span><\/li>\n<\/ul>\n
<\/p>\n
\nclass<\/span> Widget<\/span> { \/* ... *\/<\/span> };\r\n\r\n\/\/ nobody will ever want to improve My_widget (or so you thought)<\/span>\r\nclass<\/span> My_widget<\/span> final :<\/span> public<\/span> Widget { \/* ... *\/<\/span> };\r\n\r\nclass<\/span> My_improved_widget<\/span> :<\/span> public<\/span> My_widget { \/* ... *\/<\/span> }; \/\/ error: can't do that<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
\n- You can declare a virtual function as final.<\/span> That means you can not override the function in derived classes.\n
<\/ul>\n<\/li>\n<\/ul>\n\nstruct<\/span> Base\r\n{\r\n virtual<\/span> void<\/span> foo();\r\n};\r\n \r\nstruct<\/span> A :<\/span> Base\r\n{\r\n void<\/span> foo() final; \/\/ A::foo is overridden and it is the final override<\/span>\r\n};\r\n \r\nstruct<\/span> B final :<\/span> A \/\/ struct B is final<\/span>\r\n{\r\n void<\/span> foo() override; \/\/ Error: foo cannot be overridden as it's final in A<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
If you use final, you seal your class hierarchy on a class base or a virtual function base. Often that has consequences you can not oversee. The potential performance benefit of using final<\/span> should be your second thought.<\/p>\nC.140: Do not provide different default arguments for a virtual function and an overrider<\/a><\/h2>\nNot following this rule can confuse. Have a look.<\/p>\n
<\/p>\n
\n\/\/ overrider.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nclass<\/span> Base<\/span> {\r\npublic:<\/span>\r\n virtual<\/span> int<\/span> multiply(int<\/span> value, int<\/span> factor =<\/span> 2<\/span>) =<\/span> 0<\/span>;\r\n};\r\n\r\nclass<\/span> Derived<\/span> :<\/span> public<\/span> Base {\r\npublic:<\/span>\r\n int<\/span> multiply(int<\/span> value, int<\/span> factor =<\/span> 10<\/span>) override {\r\n return<\/span> factor *<\/span> value;\r\n }\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n Derived d;\r\n Base&<\/span> b =<\/span> d;\r\n\r\n std::<\/span>cout <<<\/span> \"b.multiply(10): \"<\/span> <<<\/span> b.multiply(10<\/span>) <<<\/span> std::<\/span>endl; \r\n std::<\/span>cout <<<\/span> \"d.multiply(10): \"<\/span> <<<\/span> d.multiply(10<\/span>) <<<\/span> std::<\/span>endl; \r\n\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Here is the quite surprising output of the program.<\/p>\n
![\"overrider\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/10\/overrider.png\")
<\/p>\n
What’s happening? Both objects b and d call the same function because the function is virtual and, therefore, late binding happens. This will not hold for the data such as the default arguments. They are statically bound, and early binding happens.<\/p>\n
What’s next?<\/h2>\n