The principle of the Richter substitution of the six principles of design pattern

There must be a lot of people who are just as confused about the name of this principle as I was when I first saw it. The reason for this is that the principle was first introduced in 1988 by Barbara Liskov, a woman in the MIT family name.

(The following two definitions are difficult to understand, you can start directly from the problem)

Definition 1: If the object O1 for each type is T1, there is an object O2 of type T2, so that all program P defined by T1 is substituted for O1 for all object O2, the behavior of the program P is not changed, then the type T2 is the subtype of the type T1.

definition 2: All references to base classes must be able to transparently use objects of their subclasses.

The origin of the problem: There is a functional P1, completed by Class A. Now need to expand the function P1, the function of the expansion of P, where p by the original function P1 and the new function P2 composition. The new function p is completed by subclass B of Class A, then the subclass B may cause the original function P1 to fail while completing the new function P2.

Solution: Follow the Richter substitution principle when using inheritance. When Class B inherits Class A, try not to rewrite the method of parent Class A, as well as try not to overload the method of the parent class A, in addition to adding new methods to complete the added P2.

Inheritance contains a layer of meaning: in a parent class, a method that is already implemented (as opposed to an abstract method), is actually setting a series of specifications and contracts, although it does not enforce that all subclasses must comply with these contracts, but if subclasses modify these non-abstract methods arbitrarily, they can cause damage to the entire inheritance system. The principle of the Richter substitution is to express the meaning of this layer.

Inheritance, as one of the three characteristics of object-oriented, brings about great convenience to program design, and also brings drawbacks. The use of inheritance, for example, is invasive to the program, the portability of programs increases the coupling between objects, and if a class is inherited by other classes, then when the class needs to be modified, all subclasses must be taken into account, and when the parent class is modified, all functions involving subclasses are likely to fail.

To illustrate the risk of inheritance, we need to complete a two-digit subtraction function, which is responsible for Class A.       [Java] view plain copy class a{public int func1 (int A, int b) {return a-b;           The public class client{public static void Main (string[] args) {A A = new A ();           System.out.println ("100-50=" +a.func1 (100, 50));       System.out.println ("100-80=" +a.func1 (100, 80)); }   }

Run Result:

100-50=50
100-80=20

Later, we need to add a new function: Complete the two number added, and then sum up with 100, by Class B is responsible. That is, Class B needs to complete two functions: two-digit subtraction. Add two numbers, then add 100.

Since class A already implements the first feature, Class B inherits Class A and only needs to complete the second function, as follows:[Java]  View Plain  copy class b extends a{       public int  FUNC1 (int a, int b) {           return  a+b;       }               PUBLIC INT FUNC2 (int a, int b) {            RETURN FUNC1 (a,b) +100;       }  }      public class client{       public static void  main (String[] args) {           b b =  new b ();           system.out.println ("100-50 =" + B.FUNC1 (100, 50));           system.out.println ("100-80 = "+b.func1 (100, 80));           system.out.println ("100+20+100=" + B.FUNC2 (100, 20));       }  }  

After Class B is finished, run the result:

100-50=150
100-80=180
100+20+100=220

We found that there was an error in the subtraction function that was supposed to run properly. The reason for this is that Class B inadvertently rewrites the method of the parent class when naming the method, causing all the code that runs the subtraction function to call the Class B rewrite method, resulting in an error in the original functioning function. In this case, the function that references the completion of base class A is replaced with subclass B, and an exception occurs. In practical programming, we often rewrite the method of the parent class to complete the new function, so that although simple, but the entire inheritance system reusability will be relatively poor, especially the use of polymorphic more frequently, the probability of the program running error is very large. If you do not want to rewrite the method of the parent class, it is more common practice that the original parent class and subclass inherit a more popular base class, the original inheritance relationship is removed, and the dependencies, aggregation, and combination are substituted.

The principle of the Richter substitution is that the subclass can extend the function of the parent class, but it cannot change the original function of the parent class. it contains the following 4 meanings: Subclasses can implement abstract methods of the parent class, but they cannot override non-abstract methods of the parent class. Subclasses can add their own unique methods. When a method of a subclass overloads a method of a parent class, the method's predecessor condition (that is, the method's formal parameter) is more relaxed than the input parameter of the parent class method. When a subclass's method implements an abstract method of the parent class, the method's post condition (the return value of the method) is stricter than the parent class.

It seems incredible, because we will find that in our own programming will often violate the principle of the Richter replacement, the program is still running well. So we all have questions about what would happen if I didn't have to follow the Richter replacement principle.

The consequence: the probability of a problem with your code will increase dramatically.