Design Pattern-six principles-Rivers' replacement principle

Liskov substitution principle (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 transparent to use its subclass objects.

That is to say, as long as the parent class appears, the Child class can appear, and replacing it with the Child class will not produce any errors or exceptions. However, if the child class is replaced with the parent class, a problem may occur.

This principle defines a standard for good inheritance. In simple terms, it has four meanings:

1. Subclass must fully implement the parent class Method

Define an abstract class

Public abstract class viewpoint {// traveling to Lijiang public abstract void where ();}

The following two classes implement this abstract class

Public class Lijiang extends viewpoint {@ overridepublic void where () {system. Out. println ("Welcome to Lijiang ...");}}

Public class Zhangjiajie extends viewpoint {@ overridepublic void where () {system. Out. println ("Welcome to Zhangjiajie ...");}}

The character is painted, and the class type is set in it to pass the parameter. At this time, the scenic spots to be painted are still Abstract

Public class Tutu {// define the private viewpoint of the Scenic Spot to be visited; // tu the public void setviewpoint (viewpoint) {This. viewpoint = viewpoint;} public void travelto () {system. out. println ("tu Tu is going to travel"); viewpoint. where ();}}

Scenario. Set specific scenic spots to go

Public class sence {public static void main (string ARGs []) {Tutu = new Tutu (); // set the destination tourist attraction tutu. setviewpoint (New Lijiang (); tutu. travelto ();}}

Running result:

Tu is going to travel
Welcome to Lijiang...

Ii. Subclass can have its own features

That is to say, other methods or attributes can be defined on the subclass of the class.

3. input parameters can be amplified when overwriting or implementing the parent class Method

Where the parent class can exist, the Child class can exist without changing the running result. Otherwise, no.

The parameters in the parent class, say (), are of the hashmap type and are child types of the map type. (Because the subclass range 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 ("the parent class is executed... "); Return map. values ();}}

Subclass, the parameters in say () are converted to the map type. The map range is larger than that of the hashmap type and complies with the LSP principle. Note that the statement here is not a statement that overwrites the parent class, because the parameter types are different. It is heavy load.

Import Java. util. collection; import Java. util. map;/** subclass inherits all attributes of the parent class */public class son extends father {// method input parameter type public collection say (MAP map) {system. out. println ("subclass executed... "); Return map. values ();}}

Scenario

Import Java. util. hashmap; public class home {public static void main (string ARGs []) {invoke ();} public static void invoke () {// where the parent class exists, 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 it is using the parent class or subclass to call the say method, the result is

The parent class is executed...

However, if you change the say parameter in Father to map and the say parameter in son sub-class to hashmap, the result is changed

F. Say (MAP) result: the parent class is executed...
S. Say (MAP) Result: The subclass is executed...

This will cause logical confusion. Therefore, the preconditions of the method in the subclass must be the same or wider than that of the override in the parent class.

4. output results can be reduced when overwriting or implementing the parent class Method

In fact, similar to the above, that is, the Child class where the parent class can appear, and replacing it with a Child class will not produce any errors or exceptions, and the user does not need to know whether it is a parent class or a child class. But in turn, it will not work. Where a subclass appears, the parent class may not be able to adapt. (After all, the subclass range must be greater than or equal to the parent class range)