"Yoga Mountain Night" --- Talking about "Inheritance" (1)

Summary: Inheritance is a very important feature of C , and is one of the three characteristics of OO. I hope to make a simple discussion on this, I can eliminate some confusion. What is inheriting? Inheritance is a method of organizing associated classes, and is a way to integrate data and operational behavior between Hengqi, but also notice that inheritance relationship is a strong coupling relationship. What is the purpose of inheritance? When it comes to inheritance, people will always think of the code reuse. In order not, the code reuse is just a side effect of inheritance. The main purpose of inheritance is to express an external meaningful relationship, which describes two entities in the problem domain. The behavior relationship between. In other words, inheritance is due to the realities of the problem domain, not due to the purpose of the technology within the solution.

What is the obstacle to inherit? Inherited use is not as simple as we think, there are many language characteristics that make a certain obstacle when deciding to inherit. 1. The existence of non-virtual member functions. If we determine a member function in a base class is non-virtual, it means that this function should not be redefined in the derived class. If you are redefined, the result is likely not what you expect, For example: Class a {public: void f () {cout << "A :: f" << endl;}}; class b: public a {public: void f () {cout << "b :: f" << endl;}}; a * pa = new b; PA-> f (); delete pa; here, we may expect PA-> F () to output B :: F, but actually A:: F , Of course, if there is no problem with Virtual, the key is how we can clearly determine that the function should be declared as Virtual? How to make the base class fully predict the various needs of subclasses? There is no doubt that this is a challenge! Perhaps all base class members are declared as Virtual is a simple solution, but this will greatly reduce the performance efficiency of the program. For C of the efficiency, this is a betrayal, C is more I hope that we only declare those functions that need to be redefined as Virtual. 2, excessive protection packages for base classes is a good feature, but the degree of packaging is difficult to master, such as Class A {Private: Class P {...};}; Class B: public a :: p { ...}; Experienced programmers will immediately realize that this is a mistake: I can't get A :: P, because it's private! Of course, you only need to change the private to protected, but the key is what the base class predicts what the child needs to inherit? Like an obstacle, this is also a challenge. Tian Zhen's programmer may think that as long as all members in the base class are documented as public / protected, it is good, but in fact, if our class is released, public / protected members will no longer change, otherwise it will be interrupted by customers. The code, this requires us to package the implementation details for Private, only those who have changed those who need change as public / protected permissions (the virtual function can be declared as Private, this is an exception), but the base class The designer requires so high, it is also very difficult. 3, the modular design in the base class is not more concise, effective, but for the base class, it is not easy to do effectively.

For example, we have one-point lookup tree BStree, defined as follows: Template class bstree {private: class node {public: t t; node * left; node * right; node (const t & _t): t (_t) { } ...}; node * root; ... public: void INSERT (Const T & T); ... protected: Virtual Void Doinsert (Const T & T, Node * & n); ...}; Template Void BStree :: doinsert (const t & t, node * & n) {if (n == 0) n = new node (t); else {if (t t) doinsert (T , n-> left; else doinsert (t, n-> right);}} Now, we want to define a red-hahead, define as follows: Template Class RBTree: Public BStree {protected: Class Node: PUBLIC BSTREE :: node {public: BOOL IS_RED; Node (const t & t);}; void doinsert (const t & t, bstree :: node * & n); Virtual Void Rebalance (Node * n); ... .}; Template Void BStree :: Doinsert (const t & t, node * & n) {if (n == 0) {node m = new node (t); n = m; Rebalance M);} else {if (t t) Doinsert (t, n-> left); else doinsert (t, n-> right);}} We discover BStree :: doinsert and RBTree :: doinsert code Also the same, this has a copy code operation. We know that the code replication work is very boring, easy to make mistakes, code bloated, difficulties ... so a good base class should make the derived class to copy the code, it is best not to copy . Look at our base class: Many two-point lookup tree need to create different nodes and have Rebalance operations.

Ok, we should modify the base class BStree: Template class bstree {protected: virtual node * new_node (const t & t) {return new node (t);} Virtual void rebalance (node ​​* n) { } ...}; This time doincert changes as follows: Template Void BStree :: Doinsert (const t & t, node * & n) {if (n == 0) {n = new_node (t) Rebalance (n);} else {IF (t t) Doinsert (t, n-> left); Else Doinsert (t, n-> right);}} This time the party RBTREE definition is changed to: Template Class RBTree: Public BStree {protected: node * new_node (const t & t) {return new node (t);} void Rebalance (BStree :: node * n) {... } ...}; so, the programmer does not need to copy the code. We found that if you want to make the derived class customers never copy the code, then separate the code that the derived class needs to be changed, form a separate module function (virtual), but when we don't have enough derived class information This is impossible, even if possible, the difficulty is also quite high, and the large number of virtual functions will also reduce the efficiency of the program. 4. The root of the excessive use of Friend keywords is the non-inheritance of friend relationships. We still use the above example, but do something change: Template class bstree; template class bsnode {protected: t t; bsnode (const t & t); Friend Class Bstree ;}; template Class BStree {... There is no NESTED NODE class}; here, due to the implementation details of BSNode belonging to BStree, in order to prevent BSNode derived classes from accidentally accessing members of BSNode, we put all his members Declare as protected, while making Bstree as its friend. But because RBTree is to access member of BSNode, add the non-inheritance of friends, making things complicated, usually have two ways to solve this problem: 1. State the members of BSNode as public, but this is Friend There is no meaning.

2, add an access function in the RBNode class, but there is more troubles than Friend. There are also some other choices to make people's headache, such as excessive variables in the base class, inherited attribute selection, etc. Not finished (to be renewed ...)