Dependence inversion principle of the six design principles

1. The six principles of design patterns are:

  • Single Responsibility Principle: Single responsibility principle
  • Open Closed Principle: Open and close principle
  • Liskov Substitution Principle: Liskov Substitution Principle
  • Law of Demeter: Law of Demeter
  • Interface Segregation Principle: Interface Segregation Principle
  • Dependence Inversion Principle: Dependence Inversion Principle

Combining the first letters of these six principles (two Ls are counted as one) is SOLID (solid, stable), which represents the benefits of combining these six principles: to establish a stable, flexible, and robust design. Let's take a look at the dependency inversion principle.

2. Dependence inversion principle

What is the Dependence Inversion Principle (DIP) The
dependency inversion principle contains the following three meanings:

  • High-level modules should not rely on low-level modules, both should rely on their abstractions
  • Abstraction should not depend on details
  • Details should rely on abstraction

3. Relying on the principle of inversion, where is the inversion?

Inversion in the principle of dependency inversion refers to the completely opposite way of thinking in general OO design.
For example, now you need to implement a pizzeria, what is the first thing that comes to your mind? What I think of is a pizzeria with a lot of specific pizzas, such as cheese pizza, vegetarian pizza, seafood pizza... The
pizzeria is the upper module, and the pizza is the lower module. If you draw the pizzeria and its dependent objects as a picture The picture looks like this:
Insert picture description here

That's right! Start from the top and then go down to the specific categories, but, as you can see, you don’t want the pizzeria to care about these specific categories, or the pizzeria will all rely on these specific categories. Now "upside down" your thoughts... Don't start thinking from the upper modular pizzeria, but start from the lower modular pizza, and then think about what can be abstracted. You might think that cheese pizza, vegetarian pizza, and seafood pizza are all pizzas, so they should share a Pizza interface. By the way, you want to abstract a Pizza. Okay, now I look back and rethink how to design a pizzeria.
Insert picture description here

The dependency arrows in Figure 1 are all from top to bottom, and the arrows in Figure 2 appear from bottom to top, and the dependencies are indeed "inverted".

In addition, this example also explains well that "the upper-level modules should not depend on the lower-level modules, they should all depend on abstraction." In the initial design, the higher-level module PizzaStroe directly depends on the lower-level modules (various specific Pizaa), After adjusting the design, both high-level modules and low-level modules rely on abstraction (Pizza)

Reference: "Head First Design Pattern"

Guess you like

Origin blog.csdn.net/qq_43458555/article/details/108431137