A detailed explanation of the dependency inversion principle in Java design pattern programming _java

Defined:
high-level modules should not rely on low-level modules, both of which should rely on their abstraction; abstractions should not rely on detail; detail should rely on abstraction.
The problem: Class A is directly dependent on class B, and if you want to change class A to dependent Class C, you must do so by modifying the code for Class A. In this scenario, Class A is typically a high-level module, responsible for complex business logic, Class B and Class C are low-level modules responsible for basic atomic operations, and if Class A is modified, it poses an unnecessary risk to the program.
Solution: Modify Class A to rely on interface I, Class B and Class C each implement interface I, Class A through interface I indirectly with Class B or Class C, will greatly reduce the chance to modify Class A.
The dependency inversion principle is based on the fact that abstract things are more stable than the variability of detail. The structure built on the basis of abstraction is more stable than the structure based on detail. In Java, abstraction refers to interfaces or abstract classes, details are specific implementation classes, and the purpose of using interfaces or abstract classes is to develop specifications and contracts without involving any specific operations and to give the task of presenting the details to their implementation class.
The core idea of the dependency inversion principle is interface-oriented programming, and we still use an example to illustrate what the interface-oriented programming is good for. The scene is like this, the mother tells the child the story, as long as gives her a book, she can read the book to the child to tell the story.

Example:
the situation of illegal reliance inversion

public class Student {public 
  void read (books book) { 
    System.out.println ("Students begin reading:" +book.getname ()); 
  } 
Public 
 
class Books {public 
  String GetName () {return 
    ' book '; 
  } 
} 

When students need to read the page, they need to modify the student class, which is a very unfriendly design. Here we look at examples of adherence to the dependency inversion principle.

Public interface Person {public 
  void read (reader reader); 
} 
 
Public interface Reader {public 
  String getName (); 
} 
 
public class Student implements person{ 
  @Override public 
  Void Read (reader reader) { 
    System.out.println (" Students begin reading: "+reader.getname ()); 
  } 
} 
 
public class Books implements Reader {public 
  String GetName () {return 
    ' book '; 
  } 
} 
 
public class Website implements Reader {public 
  String GetName () {return 
    Web page; 
  } 
} 
 
public class Test {public 
  static void Main (string[] args) {person 
    student = new Student (); 
    Student.read (new book ()); 
    Student.read (New Website ()); 
  } 
 

In the Read method we use an interface as an argument.

Summarize:
1. Each class is best to have an interface or abstract class, or both interfaces and abstract classes.
2. Variable declarations are preferably interfaces or abstract classes.
3. Follow the principle of the Richter substitution in succession.