On the Richter scale replacement principle--seven object-oriented design principles (2)

Richter Replacement Principle Source:

we all know that object-oriented has three main features: encapsulation, inheritance, polymorphism. Therefore, in the actual development process, the subclass after inheriting the parent class, depending on the characteristics of polymorphism, may be convenient for the diagram, often arbitrarily rewrite the parent class method, then this way will greatly increase the probability of code problems. For example, the following scenario: ClassCimplements a functionF1. Now you need the functionalityF1To Modify the extension, the functionF1extended toF, whereFby the original functionF1and new featuresF2composition. New featuresFby the classCsub-classC1to complete, the child classC1in the completion functionFat the same time, it is possible to cause the classCthe original functionF1The failure occurs. Then someone put forward the principle of the Richter replacement. The principle of the Richter replacementThis principle was first1988MIT, a woman surnamed Li (Liskov) is proposed.

The Richter replacement principle defines:

        Strict definition: t1 o1 , there are objects of type t2 o2 t1 All programs defined by p o1 o2 p The behavior has not changed, then the type t2 is type t1  

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

More popular definition: Subclasses can extend the functionality of the parent class, but cannot change the original functionality of the parent class.

That is, in object-oriented design, if you replace a subclass object with a base class object, the program does not get an error, but the software entity uses a subclass object, but the entity does not necessarily use the base class object of the subclass, and if so, the program may have problems.

For example, there are two classes, one class is ClassA, the other is the ClassB class, and the ClassB class is a subclass of the ClassA class, so if a method can accept base class object base of a ClassA type, such as: MethodA (Base), Then it is bound to accept a subclass object of type ClassA Sub,methoda (sub) to function properly. Conversely, substitution is not tenable, such as a method MethodB accepts a subclass object of type ClassA as a parameter: MethodB (sub), then generally there is no MethodB (base), unless it is an overloaded method.

Example: The Richter replacement of the data request for the Shenzhen-A-share plate:

                                       

In this example, you can consider adding a new abstract class Stockblock, and Shanga and Shena classes as their subclasses, the data request class quote class for the abstract customer class Stockblock programming, according to the principle of the Richter substitution, The place where the base class object can be accepted is bound to accept the subclass object, so change the parameter type of the request () method in quote to code, and if you need to add a new type of customer, just use it as a subclass of the string class. The reconstructed structure is shown in 2:

Richter Replacement Use Summary:

The Richter replacement consists of the following four levels of meaning:

(1). Subclasses can implement an abstract method of the parent class, but cannot override the non-abstract method of the parent class.

(2). Subclasses can add their own unique methods.

(3). When a method of a subclass overloads a method of the parent class, the method's preconditions (that is, the parameter of the method) are more lenient than the input parameters of the parent class method.

(4). When a method of a subclass implements an abstract method of the parent class, the post condition of the method (that is, the return value of the method) is stricter than the parent class.

On the Richter scale replacement principle--seven object-oriented design principles (2)