Reprinted, the original link https://www.cnblogs.com/zhanghengscnc/p/8299459.html
Definition: high-level modules should not depend on low-level modules, both of which should rely on its abstract; abstract should not rely on details; details should depend on the abstract.
The origin of the problem: A direct dependency class Classes B, if you want to rely on Class A Class C, the code modification must be achieved by the class A. In this scenario, the class A layer module is generally responsible for complex business logic; class B and class C is a low-level module that is responsible for the basic atomic operation; class A if modified, the program will bring unnecessary risk.
Solution: A Review of the class dependent interfaces I, Class B and C each implement an interface I, class A contact occurs indirectly via the interface I Class B or Class C, will greatly reduce the risk of class A modified.
Dependency Inversion principle based on the fact: relative variability detail, abstract things much more stable. Abstract-based architecture to build up much more stable than to build up detail based architecture. In java, abstract refers to the interface or abstract class, detail is the purpose of a specific category, use an interface or an abstract class is to develop a good standard and contract, not to involve any specific action, to show the details of the task to their implementation class to complete.
Dependency Inversion principle is the core idea interface-oriented programming, we still use an example to illustrate oriented programming interface than with respect to programming Fortunately, somewhere oriented implementation. The scene is like this, mother telling stories to children, just give her a book, she can give the child according to the books tell the story. code show as below:
class Book { public function getContent() { return "Once upon a time there is an Arab story ......" ; } } class Mother { public function narrate(Book $book) { echo "my mother began to tell stories:" ; echo $ Book -> getContent (); } } Mother $ = new new Mother (); $ Mother -> narrate ( new new Book ()); // mother began to tell a story: Once upon a time there is an Arab story ......
Running well, if one day, demand becomes this: not to book but to a newspaper, let the mother talk about the story in the newspaper, the newspaper's code is as follows:
class Newspaper { public function getContent() { return "team won the 2018-2019 season, the Toronto Raptors NBA championship" ; } }
The mother could not do, because she had not read the story in the newspaper, which is ridiculous, just book into a newspaper, but still must be modified to read Mother. If the magazine into the future demand for it? Web page into it? But also continue to modify Mother, this is clearly not good design. The reason is that the coupling between the Mother and the Book is too high, the job must reduce the coupling between them.
We introduce an abstract interface IReader. Books, as long as the books are all with the word:
interface IReader { public function getContent(); }
Mother classes and interfaces IReader happen dependencies, and Book and Newspaper belong to the category of books, they each have to realize IReader interfaces, so in line with the principle of dependency inversion, the code is amended as follows:
interface IReader { public function getContent(); } class Book implements IReader { public function getContent() { return "Once upon a time there is an Arab story ......" ; } } class Newspaper implements IReader { public function getContent() { return "team won the 2018-2019 season, the Toronto Raptors NBA championship" ; } } class Mother { public function narrate(IReader $ireader) { echo "my mother began to tell stories:" ; echo $ ireader -> getContent (); } } Mother $ = new new Mother (); $ Mother -> narrate ( new new Book ()); // mother began to tell a story: Once upon a time there is an Arab story ...... $ Mother -> narrate ( new new Newspaper ()); / / mother began to tell stories: Toronto Raptors NBA team won the 2018-2019 championship season
This amendment, no matter how the future expansion of the Client class, do not need to modify the Mother class. This is just a simple example, the actual situation, the high-level representatives of the Mother class module will be responsible for completing the main business logic, once the need to modify it, introducing errors risky. Therefore, following the Dependency Inversion Principle can reduce the coupling between classes, and improve system stability and reduce the risk due to modify the program.
Dependency Inversion principle to the use of more than parallel development has brought great convenience, such as the example above, the original Mother class directly coupled with the Book class, the class must wait before Mother Book class-encoded can be encoded, because Mother dependent class in the Book category. The modified program can be started simultaneously, independently of each other, because Mother and Book class has nothing to do. The more people involved in collaborative development, the huge project, leading to rely on the use of the more significant principles. Now very popular TDD development model is dependent on the principle of inversion of the most successful applications.
There are three ways to transfer the dependency, the method used in the above example is an interface transfer, there are two other delivery methods: constructor passing and setter methods passed, I believe used Spring Framework, transfer mode will not be unfamiliar to rely on .
In actual programming, we generally need to do the following three points:
- Lower block as far as possible should have an abstract class or interface, or both.
- Declare the types of variables as much as possible is an abstract class or interface.
- Richter substitution principle to follow when using inheritance.
Dependency Inversion principle is the core of our programming to interfaces to understand the interface-oriented programming, also understand Dependency Inversion.