What is the Liskov substitution principle of Java design patterns?

Liskov Substitution Principle (Liskov Substitution Principle), referred to 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 places that reference a base class must be able to transparently use its subclass objects.

In other words, as long as the parent class appears, the subclass can appear, and replacing it with the subclass will not cause any errors or exceptions. But conversely, where subclasses appear, problems may arise if they are replaced by parent classes.

This principle is to define a specification for good inheritance. Simply put, it has four levels of meaning:

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

Define an abstract class

public abstract class ViewPoint {      //去丽江旅游      public abstract void where();  }

The following two classes implement this abstract class

public class Lijiang extends ViewPoint {         @Override     public void where() {          System.out.println("欢迎来到丽江...");      }     }   public class Zhangjiajie extends ViewPoint {         @Override     public void where() {          System.out.println("欢迎来到张家界...");      }     }

The character is Tutu, and the class type is set inside to pass parameters. At this time, the tourist attractions Tutu wanted to visit were still abstract

public class Tutu {      //定义要旅游的景点      private ViewPoint viewpoint;      //涂涂要去的景点      public void setViewPoint(ViewPoint viewpoint)      {          this.viewpoint = viewpoint;      }             public void travelTo()      {          System.out.println("涂涂要去旅游了");          viewpoint.where();      }  }

scenes. Set the specific attractions to go to

public class Sence {      public static void main(String args[])      {          Tutu tutu = new Tutu();          //设置要去的旅游景点          tutu.setViewPoint(new Lijiang());          tutu.travelTo();      }  }

Run results:

Tutu is going to travel
Welcome to Lijiang...

2. Zi A class can have its own characteristics

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

3. Override or implement the methods of the parent class When the input parameters can be enlarged

where the parent class can exist, the subclass can exist, and there will be no change in the running results. The reverse is not true.

Parent class, the parameter in say() is of HashMap type, which is a subtype of 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("父类被执行...");          return map.values();      }  }

For the subclass, the parameters in say() become the Map type. The Map range is larger than the HashMap type, which is in line with the LSP principle. Note that the say here does not overwrite the parent class's say because the parameter types are different. But overload.

import java.util.Collection;  import java.util.Map;     /*   * 子类继承了父类的所有属性   */ public class Son extends Father {      //方法输入参数类型      public Collection say(Map map)      {          System.out.println("子类被执行...");          return map.values();      }  }

Scene class

import java.util.HashMap;     public class Home {      public static void main(String args[])      {          invoke();      }             public static void invoke()      {          //父类存在的地方，子类就应该能够存在          //Father f = new Father();          Son s = new Son();          HashMap map = new HashMap();          //f.say(map);          s.say(map);      }  }

Whether the say method is called with the parent class or the subclass, the result is that the parent class is executed...

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

f.say(map) result: parent class Executed...

s.say(map) result: The subclass is executed...

This will cause logical confusion. Therefore, the preconditions of methods in the subclass must be the same as or wider than the overridden preconditions in the parent class.

4. When overriding or implementing the method of the parent class, the output result can be reduced

In fact, it is similar to the above, that is, the subclass can appear where the parent class can appear It can appear, and replacing it with a subclass will not cause any errors or exceptions, and the user does not need to know whether it is a parent class or a subclass. But the opposite is not true. Wherever subclasses appear, the parent class may not adapt. (After all, the scope of the subclass must be >= the scope of the parent class)

The above is the detailed content of What is the Liskov substitution principle of Java design patterns?. For more information, please follow other related articles on the PHP Chinese website!