Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the Richter replacement principle of Java design pattern". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the Richter replacement principle of Java design pattern".

Richter permutation principle (Liskov Substitution Principle), abbreviated as LSP

Definition:

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

All references to the base class must be able to use its subclass objects transparently.

That is, a subclass can appear as long as the parent class occurs, and replacing it with a subclass does not produce any errors or exceptions. But conversely, where the subclass appears, replacing it with the parent class may have a problem.

This principle defines a specification for good inheritance. To put it simply, it has four meanings:

1. The subclass must fully implement the methods of the parent class

Define an abstract class

Public abstract class ViewPoint {/ / travel to Lijiang public abstract void where ();}

The following two classes implement this abstract class

Public class Lijiang extends ViewPoint {@ Override public void where () {System.out.println ("Welcome to Lijiang...");} public class Zhangjiajie extends ViewPoint {@ Override public void where () {System.out.println ("Welcome to Zhangjiajie...");}}

The character is smeared, in which the class type is set to pass parameters. At this time, the tourist attractions you are going to visit are still abstract.

Public class Tutu {/ / define scenic spots to visit private ViewPoint viewpoint; / / paint scenic spots to visit public void setViewPoint (ViewPoint viewpoint) {this.viewpoint = viewpoint;} public void travelTo () {System.out.println ("painting is going to travel"); viewpoint.where ();}}

Scene class. Set up specific scenic spots to go to

Public class Sence {public static void main (String args []) {Tutu tutu = new Tutu (); / / set the tourist attractions tutu.setViewPoint (new Lijiang ()); tutu.travelTo ();}}

Running result:

Tu Tu is going on a trip.

Welcome to Lijiang.

Second, subclasses can have their own characteristics

That is, on a subclass of a class, other methods or properties can be defined

Third, the input parameters can be enlarged when overriding or implementing the methods of the parent class

Where the parent class can exist, the subclass can exist and will not change the result of the run. On the other hand, no.

The parent class, the parameter in say () is the HashMap type, which is a subtype of the Map type. (because the scope of the subclass should be larger than the parent class)

Import java.util.Collection; import java.util.HashMap; public class Father {public Collection say (HashMap map) {System.out.println ("parent class is executed..."); return map.values ();}}

Subclass, the parameter in say () becomes the Map type, and the Map range is larger than the HashMap type, which conforms to the LSP principle. Note that the say here is not the say that overrides the parent class, because the parameter types are different. It's overloaded.

The import java.util.Collection; import java.util.Map; / * * subclass inherits all the properties of the parent class * / public class Son extends Father {/ / method input parameter type public Collection say (Map map) {System.out.println ("subclass is executed..."); return map.values ();}}

Scene class

Import java.util.HashMap; public class Home {public static void main (String args []) {invoke ();} public static void invoke () {/ / where the parent class exists, the subclass should be able to exist / / Father f = new Father (); Son s = new Son (); HashMap map = new HashMap () / / f.say (map); s.say (map);}}

Whether you call the say method with a parent class or a subclass, the result is

The parent class is executed.

However, if you change the say parameter in the above Father to Map and the say parameter in the subclass Son to HashMap, the result will be

F.say (map) result: the parent class is executed.

S.say (map) result: the subclass is executed.

This will cause logical confusion. So the precondition of the method in the subclass must be the same or wider than the precondition overridden in the parent class.

Fourth, the output can be reduced when overriding or implementing the method of the parent class.

In fact, similar to the above, that is, where a parent class can appear, a subclass can appear, and replacing it with a subclass does not produce any errors or exceptions, and the user does not need to know whether it is a parent class or a subclass. But the reverse is not good, where there is a subclass, the parent class may not adapt. (after all, the scope of the subclass > = the scope of the parent class)

Thank you for your reading, the above is the content of "what is the Richter replacement principle of Java design pattern". After the study of this article, I believe you have a deeper understanding of what the Richter replacement principle of Java design pattern is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.