Detailed examples of dependency inversion principle in Java

This article mainly introduces the definition of Java dependency inversion principle and the solution to the problem. Friends who are interested should take a look

Definition: High-level modules should not depend on low-level modules , both should depend on their abstractions; abstractions should not depend on details; details should depend on abstractions.

Origin of the problem: Class A directly depends on class B. If you want to change class A to depend on class C, you must modify the code of class A. In this scenario, class A is generally a high-level module responsible for complex business logic; classes B and C are low-level modules responsible for basic atomic operations; if class A is modified, it will bring unnecessary risks to the program.

Solution: Modify class A to depend on interface I, class B and class C each implement interface I, class A indirectly contacts class B or class C through interface I, then It will greatly reduce the chance of modifying Category A.

The dependency inversion principle is based on the fact that abstract things are much more stable than the variability of details. An architecture built on abstraction is much more stable than an architecture built on details. In Java, abstraction refers to interfaces or abstract classes, and details are specific implementation classes. The purpose of using interfaces or abstract classes is to formulate specifications and contracts without involving any specific operations, leaving the task of showing the details to Their implementation class to complete.

The core idea of ​​the dependency inversion principle is interface-oriented programming. We still use an example to illustrate how interface-oriented programming is better than implementation-oriented programming. The scene is like this. A mother tells a story to her child. As long as she is given a book, she can tell the story to her child according to the book. The code is as follows:

class Book{ 
 public String getContent(){ 
  return "很久很久以前有一个阿拉伯的故事……"; 
 } 
} 
class Mother{ 
 public void narrate(Book book){ 
  System.out.println("妈妈开始讲故事"); 
  System.out.println(book.getContent()); 
 } 
} 
public class Client{ 
 public static void main(String[] args){ 
  Mother mother = new Mother(); 
  mother.narrate(new Book()); 
 } 
}

Running results:

Mom starts telling stories

A long time ago There is an Arab story...

It is running well. If one day, the demand becomes like this: instead of giving a book, give a newspaper, and let the mother tell the story in the newspaper. The newspaper The code of , actually you have to modify Mother to read it. What if I need to switch to a magazine in the future? What about replacing it with a web page? You have to constantly modify the Mother, which is obviously not a good design. The reason is that the coupling between Mother and Book is too high, and the coupling between them must be reduced.

We introduce an abstract interface IReader. Readings, as long as they have words, are readings:

class Newspaper{ 
 public String getContent(){ 
  return "林书豪38+7领导尼克斯击败湖人……"; 
 } 
}

Run results:

Mom starts telling stories

A long time ago An Arab story...

Mom starts telling the story

Jeremy Lin helped the Knicks defeat the Hawks with 17+9...

Modified like this Finally, no matter how the Client class is extended in the future, there is no need to modify the Mother class. This is just a simple example. In actual situations, the Mother class representing the high-level module will be responsible for completing the main business logic. Once it needs to be modified, the risk of introducing errors is extremely high. Therefore, following the dependency inversion principle can reduce the coupling between classes, improve the stability of the system, and reduce the risks caused by modifying the program.
The adoption of the dependency inversion principle brings great convenience to multi-person parallel development. For example, in the above example, when the Mother class and the Book class were directly coupled, the Mother class must wait until the Book class coding is completed. Coding can be done because the Mother class depends on the Book class. The modified programs can be started at the same time without affecting each other, because the Mother and Book classes have nothing to do with each other. The more people involved in collaborative development and the larger the project, the more significant it is to adopt the dependency-causing principle. The now popular TDD development model is the most successful application of the dependency inversion principle.

There are three ways to transfer dependencies. The method used in the above example is interface transfer. There are also two transfer methods: constructor method transfer and setter method transfer. I believe those who have used the Spring framework, You must be familiar with the way dependencies are passed.

In actual programming, we generally need to do the following three points:

Low-level modules must have abstract classes or interfaces, or both.

• The declared type of a variable should be an abstract class or interface as much as possible.

• Follow the Liskov substitution principle when using inheritance.

• The core of the dependency inversion principle is that we program for interfaces. If we understand interface-oriented programming, we also understand dependency inversion.

The above is the detailed content of Detailed examples of dependency inversion principle in Java. For more information, please follow other related articles on the PHP Chinese website!