Detailed explanation of the Richter substitution principle and the principle of dependency inversion among the six principles of design patterns

Six principles of design patterns-detailed explanation of the Richter substitution principle and the principle of dependency inversion


1. Liskov Substitution Principle

  • concept

    As the name suggests, this principle is used where replacement often occurs. In Java, it refers to the principle of abstraction and mutual replacement of parent and child classes . It is one of the basic principles of object-oriented design.

  • Content
    Sample source code:

Animal abstract class:

public abstract class Animal{
    //抽象方法
    public abstract void eat();
}

House subclass:

public class Horse extends Animal{
    @Override
    public void eat() {
    	System.out.println("马吃草");
    }
    //因为参数与父类不同,所以也是特有方法
    public void eat(String food) {
        System.out.println("马吃" + food);
    }
}

Bird subclass source code:

public class Horse extends Animal{
	//继承父类的方法
    public void eat() {
    	System.out.println("鸟吃食");
    }
    //自己特有的方法
    public void fly() {
    	System.out.println("鸟在飞");
    }
}

LSPTest test class:

public class LSPTest {
    public static void main(String[] args) {
        //声明基类对象
        Animal animal;
        //使用基类指向子类
        animal = new Horse();
        animal.eat();
        //使用基类指向子类
        animal = new Bird();
        animal.eat();

        //Horse horse = new Animal(); 错误
    }
}

It contains the following four criteria:

  1. The subclass must fully implement the methods of the parent class
  2. Subclasses can have their own unique methods
  3. The input parameter of the subclass is the subclass of the input parameter of the parent class or is consistent with it
  4. The return type of the subclass is a subclass of or consistent with the return type of the parent class
  • to sum up

    Inherited advantages:

    1. Reduce the workload of creating classes , because each subclass has the properties and methods of the parent class;
    2. Improved code reusability
    3. Improved scalability , because subclasses can have their own unique methods and properties.

    Of course, inheritance also has disadvantages:

    1. Inheritance is intrusive and reduces the flexibility of the code , because after inheritance, you have to have the methods and properties of the parent class whether you like it or not
    2. Increased coupling , once the parent class changes, all subclasses are equivalent to have been changed

2. Dependence Inversion Principle

  • concept

    Traditional design methods tend to rely on high-level modules on low-level modules, and abstract levels on specific levels. The "inversion principle" corrected this error and was named the "dependency inversion principle".

    It contains three meanings:

    1. High-level modules should not depend on low-level modules, both of which depend on their abstract classes
    2. Abstraction does not depend on details
    3. Details should depend on abstraction

    Performance in java:

    1. The dependencies between modules are generated through abstraction, and there is no direct dependency between implementation classes. The dependencies are generated through interfaces or abstract classes.
    2. The interface or abstract class does not depend on the implementation class, and the implementation class depends on the interface or abstract class
  • content

    In layman's terms, the principle of dependency inversion is one of the essence of "interface-oriented programming"-OOD (Object-Oriented Design).

    The following is a diagram:

Insert picture description here

It is not difficult to see that the essence of dependency inversion is to make the realization of each class or module independent of each other through abstraction (interface or abstract class), without affecting each other, and to achieve loose coupling between modules.

  • to sum up

    1. Each class should have an interface or an abstract class, or a colleague should have an abstract class and an interface, this is a prerequisite for dependency inversion, and only with abstraction can dependency inversion
    2. No type should be derived from a concrete class, that is, it should be derived from an abstract class or interface
    3. Try not to override the method of the base class
    4. To be used in conjunction with the Richter substitution principle (inheritance specification)

Guess you like

Origin blog.csdn.net/weixin_44829930/article/details/109770971