The sixth chapter of effective C + +: Inheritance and object-oriented design
- Make sure that your public inherits the is-a relationship from the mold. Student is a person, so student can inherit public from person. Conceptually, a square is a rectangle, but if you let square inherit from rectangle, does square need to have a length and width of two member variables like rectangle? If so, it's strange to change the length of the square every time it changes the width of the square, isn't it? So is-a relationships are not only real-world concepts, but also implementations, ensuring that everything that happens to a base class object is natural to the derived class object, because public means is-a relationships.
- Avoid hiding the inherited name. When public inherits, if there is a function with the same name as the base class within the derived class, the function in the derived class will block out those in the base class, regardless of virtual, parameter type, or const (not one, But all) functions, because of the lookup rule when the compiler resolves a function name. Shielding the functions in base class is often not what we want because derived class object Is-a base class object. The solution is to add the statement using::member_function_name in the derived class declaration; just member_function_name nothing else.
- Differentiate between interface inheritance and implementation inheritance. The following rules are valid for public inheritance:
1) The interface of the member function is always inherited.
2) The pure virtual function is intended to inherit the interface.
3) Impure The purpose of the virtual function is to inherit the interface and a default implementation, derived class can override the implementation.
4) The Non-virtual function--in the case of not violating the previous one--is to inherit the interface and a non-changing implementation.
Design a reasonable interface and choose the type of inheritance you want.
- Consider alternatives other than the virtual function. In order to express polymorphism, there are other options, in addition to the simple inheritance of virtual functions, which can be:
1) Non-virtual interface method (this refers to the template approach in design mode, not the template in C + +). This avoids a lot of repetitive code, just making a small part of the changes in Non-virtual interface into virtual.
2) Strategy mode. C + + has a variety of programming paradigms, so there are many ways to implement strategy. You can use the traditional strategy method in design mode (with polymorphism), you can also take advantage of function pointers, you can use functor (functor), and you can use delegates, eh? A delegate in C + +? You can simulate, using templates, my previous blog post uses C++11 's new features to simply simulate a c++11 analog C # delegate, c++98, it takes a lot of effort. Delegates can take advantage of function pointers and functor, the difference being that delegates are more flexible than these two bits.
- Never redefine the inherited non-virtual function. OK, this is consistent with the previous content, remember the four semantics of the function interface? Again, design a reasonable interface and choose the type of inheritance you want.
- Never redefine inherited default parameters. Following the previous one, let the face of the article shrink a bit, virtual means dynamic (depending on the actual type of runtime), and the default means static (compile-time determined), if you want a dynamic interface to have static parameters, when you use polymorphism, in the derived class default parameters regardless of how you rewrite, are from the base class, and the function that runs is the derived version. If you want to overwrite the default parameters, the result is definitely not what you want. It is best to consider rewriting the virtual interface using an alternative method, and if not, consider the appropriateness of the design. In summary, do not redefine inherited default parameters, and redefine has no effect.
- By compounding the has-a semantics or "realizing out of something" semantics. A has B, then use the compound, a some operations need to do some of the operation of B, but B is not a A, you can also use the composite, try to avoid the use of inheritance, which will bring low cohesion and tight coupling of class design problems. The compound can be in the form of a Class B member, or a member function in Class A uses the Class B object as a parameter.
- Use private inheritance wisely and prudently. If you use private inheritance, the compiler does not convert the derived class to a base class; The members (functions and variables) that inherit from the base class become private. This means that inherited things are only implementation-level, not externally accessible, so there is no design dimension involved, and, according to the previous article, it is best to use a composite substitution. If you still need to inherit from private if you consider a variety of alternatives, you can use it.
- Use multiple inheritance wisely and prudently. Multiple inheritance is useful, but multiple inheritance is often more complex than single inheritance and tends to lead to an increase in the probability of ambiguity (do you remember the diamond type structure?). , virtual inheritance is a way to resolve ambiguity, but it has to pay the cost of space, efficiency, initialization complexity, for virtual base class as far as possible, if used, do not put data members. One application scenario for multiple inheritance is a two-phase combination of "public inherits from a interface class" and "private inherits from a class that is implemented by a certain assistance."
"Effective C + +" highlights (vi)
