![\"\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/10\/hierarchy.png\")
<\/p>\nIn the last post, I started our journey with the rules of class hierarchies in modern C++. The first rules had a pretty general focus. This time, I will continue our journey. Now, the rules have a closer focus.<\/p>\n
<\/p>\n
Here are the 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 the fourth one.<\/p>\n
C.129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance<\/a><\/h3>\nAt first, what is the difference between implementation inheritance and interface inheritance? The guidelines give a definite answer. Let me cite it.<\/p>\n
\n- interface inheritance<\/strong> is the use of inheritance to separate users from implementations, in particular, to allow derived classes to be added and changed without affecting the users of base classes.<\/li>\n
- implementation inheritance<\/strong> is the use of inheritance to simplify the implementation of new facilities by making useful operations available for implementers of related new operations (sometimes called \u201cprogramming by difference\u201d).<\/li>\n<\/ul>\n
Pure interface inheritance will occur if your interface class only has pure virtual functions. In contrast, you have an implementation inheritance if your base class has data members or implemented functions. The guidelines give an example of mixing both concepts. <\/p>\n
<\/p>\n
\nclass<\/span> Shape<\/span> { \/\/ BAD, mixed interface and implementation<\/span>\r\npublic:<\/span>\r\n Shape();\r\n Shape(Point ce =<\/span> {0<\/span>, 0<\/span>}, Color co =<\/span> none):<\/span> cent{ce}, col {co} { \/* ... *\/<\/span>}\r\n\r\n Point center() const<\/span> { return<\/span> cent; }\r\n Color color() const<\/span> { return<\/span> col; }\r\n\r\n virtual<\/span> void<\/span> rotate(int<\/span>) =<\/span> 0<\/span>;\r\n virtual<\/span> void<\/span> move<\/span>(Point p) { cent =<\/span> p; redraw(); }\r\n\r\n virtual<\/span> void<\/span> redraw<\/span>();\r\n\r\n \/\/ ...<\/span>\r\npublic:<\/span>\r\n Point cent;\r\n Color col;\r\n};\r\n\r\nclass<\/span> Circle<\/span> :<\/span> public<\/span> Shape {\r\npublic:<\/span>\r\n Circle(Point c, int<\/span> r) :<\/span>Shape{c}, rad{r} { \/* ... *\/<\/span> }\r\n\r\n \/\/ ...<\/span>\r\nprivate:<\/span>\r\n int<\/span> rad;\r\n};\r\n\r\nclass<\/span> Triangle<\/span> :<\/span> public<\/span> Shape {\r\npublic:<\/span>\r\n Triangle(Point p1, Point p2, Point p3); \/\/ calculate center<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
Why is the class Shape<\/span> bad?<\/p>\n\n- The more the class grows, the more difficult and error-prone it may become to maintain the various constructors.<\/li>\n
- The functions of the Shape<\/span> class may never be used.<\/li>\n
- If you add data to the Shape<\/span> class, a recompilation may become probable.<\/li>\n<\/ul>\n
Shape<\/span> wouldn’t need a constructor if it were a pure interface consisting only of pure virtual functions. Of course, with a pure interface, you must implement all functionality in the derived classes.<\/p>\nHow can we get the best of two worlds: stable interfaces with interface hierarchies and code reuse with implementation inheritance? One possible answer is dual inheritance. Here is a pretty sophisticated receipt for doing it.<\/p>\n
1. Define the base Shape<\/span> of the class hierarchy as a pure interface<\/strong><\/p>\n\n<\/ol>\n<\/ol>\n\nclass<\/span> Shape<\/span> { \/\/ pure interface<\/span>\r\npublic:<\/span>\r\n virtual<\/span> Point center() const<\/span> =<\/span> 0<\/span>;\r\n virtual<\/span> Color color() const<\/span> =<\/span> 0<\/span>;\r\n\r\n virtual<\/span> void<\/span> rotate(int<\/span>) =<\/span> 0<\/span>;\r\n virtual<\/span> void<\/span> move(Point p) =<\/span> 0<\/span>;\r\n\r\n virtual<\/span> void<\/span> redraw() =<\/span> 0<\/span>;\r\n\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
2. Derive a pure interface Circle<\/span> from the Shape<\/span><\/strong><\/p>\n<\/p>\n
\nclass<\/span> Circle<\/span> :<\/span> public virtual ::<\/span>Shape { \/\/ pure interface<\/span>\r\npublic:<\/span>\r\n virtual<\/span> int<\/span> radius() =<\/span> 0<\/span>;\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
3. Provide the implementation class Impl::Shape <\/span><\/strong><\/p>\n<\/p>\n
\nclass<\/span> Impl<\/span>::<\/span>Shape :<\/span> public virtual<\/span> ::Shape { \/\/ implementation<\/span>\r\npublic:<\/span>\r\n \/\/ constructors, destructor<\/span>\r\n \/\/ ...<\/span>\r\n Point center() const<\/span> override { \/* ... *\/<\/span> }\r\n Color color() const<\/span> override { \/* ... *\/<\/span> }\r\n\r\n void<\/span> rotate(int<\/span>) override { \/* ... *\/<\/span> }\r\n void<\/span> move(Point p) override { \/* ... *\/<\/span> }\r\n\r\n void<\/span> redraw() override { \/* ... *\/<\/span> }\r\n\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
4. Implement the class Impl::Circle<\/span> by inheriting from the interface and the implementation<\/strong><\/p>\n<\/p>\n
\nclass<\/span> Impl<\/span>::<\/span>Circle :<\/span> public virtual<\/span> ::Circle, public<\/span> Impl::<\/span>Shape { \/\/ implementation<\/span>\r\npublic:<\/span>\r\n \/\/ constructors, destructor<\/span>\r\n\r\n int<\/span> radius() override { \/* ... *\/<\/span> }\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
5. If you want to extend the class hierarchy, you have to derive from the interface and the implementation <\/strong> <\/span><\/p>\nThe class Smiley<\/span> is a pure interface derived from Circle.<\/span> The class Impl::Smiley<\/span> is the new implementation, public derived from Smiley<\/span> and Impl::Circle<\/span>.<\/p>\n<\/p>\n
\nclass<\/span> Smiley<\/span> :<\/span> public virtual <\/span>Circle { \/\/ pure interface<\/span>\r\npublic:<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n\r\nclass<\/span> Impl<\/span>::<\/span>Smiley :<\/span> public virtual<\/span> ::Smiley, public<\/span> Impl::<\/span>Circle { \/\/ implementation<\/span>\r\npublic:<\/span>\r\n \/\/ constructors, destructor<\/span>\r\n \/\/ ...<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Here is once more the big picture of the two hierarchies.<\/p>\n
\n- interface: Smiley -> Circle -> Shape<\/span><\/li>\n
- implementation: Impl::Smiley -> Imply::Circle -> Impl::Shape<\/span><\/li>\n<\/ul>\n
<\/p>\n
By reading the last lines, maybe you had a d\u00e9j\u00e0 vu. You are right. This technique of multiple inheritances is similar to the adapter pattern,<\/a> implemented with multiple inheritances. The adapter pattern is from the well-known design pattern<\/a> book.<\/p>\nThe idea of the adapter pattern is to translate an interface into another interface. You achieve this by inheriting public from the new interface and private from the old one. That means you use the old interface as an implementation.<\/p>\n
![\"AdapterrClass\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/10\/AdapterrClass.png\")
<\/p>\n
C.130: Redefine or prohibit copying for a base class; prefer a virtual clone<\/code> function instead<\/a><\/h3>\nI can make it relatively short. Rule C.67<\/a> gives a reasonable explanation for this rule.<\/p>\n<\/p>\nC.131: Avoid trivial getters and setters<\/a><\/h3>\nIf a trivial getter or setter provides no semantic value, publicize the data item. Here are two examples of trivial getters and setters:<\/p>\n
<\/p>\n
\nclass<\/span> Point<\/span> { \/\/ Bad: verbose<\/span>\r\n int<\/span> x;\r\n int<\/span> y;\r\npublic:<\/span>\r\n Point(int<\/span> xx, int<\/span> yy) :<\/span> x{xx}, y{yy} { }\r\n int<\/span> get_x()