Read "Zen of design patterns" by Qin Xiaobo and ask 1-Dependency inversion principle

This "Zen of design patterns" was not easy to get. At that time, I had the honor to ask Qin Xiaobo in the csdn forum. Reading such a classic book cannot be like reading a novel. It is intended to be a pleasure to go around for a long time. It is more about reading and changing questions. Why should we ask every key point. Teacher Qin Xiaobo's language is sometimes humorous and sometimes important. Mr. Qin Xiaobo explained the question of "Inverted" from the perspective of human thinking. In his life, for example, Zhang San relied on his family's BMW to go to work, maybe more specific to the BMW 740li, then we will return to the program. If we build the dependency in this way, if James is developed one day and Maserati is changed, will the whole program have to be changed, at this time, we can turn the object on which Michael is dependent into an interface or abstract class, for example, a "car". If Michael is changed to Maserati, we can add a "Maserati" Car implementation. When dependency is not specific but abstract, this transformation of thinking is called inversion.

In the code listing 3-8 on page 1 of this book, you will see

Code 1

 
Public static void main (string [] ARGs) {// todo auto-generated method stub/* driver Jim = new driver (); BMW = new BMW (); */idriver Jim = new driver (); icar bmw = new BMW (); Jim. drive (BMW );}
 

I used to write comments in the past, but I did not write comments in my book, after thinking about this problem for a long time, I realized that the Jim object in the annotation not only has methods in the interface, but also has methods in the driver class, however, the Jim object without comments only has methods in the interface. For example, if the driver class still has a car repair method, then the new object of teacher Qin cannot call the car repair method. The Code is as follows:

Code 2

 
Public class driver implements idriver {@ override public void drive (ICAR car) {// todo auto-generated method stub car. run ();} public void fix () {system. out. println ("I can fix my car ");}}
 

On the 25 pages of the book, constructors are used to transmit dependent objects. Instructor Qin did not explain why this was necessary. From Code 2, we can see that ICAR is directly passed in as a parameter. In this way, not only does the drive method of the interface idriver need this parameter, in the future, any class that implements this interface must do so, which undoubtedly increases the Coupling Degree of the program. Let's take a look at the following code.

Code 3

 
Public class driver implements idriver {private ICAR car; Public Driver (ICAR _ car) {This. car = _ car;} public void drive () {This. car. run ();}}
 

From Code 3, we can see that the constructor is added and the dependent ICAR object is passed through the constructor. In this way, no parameters are required for the drive method in the idriver interface. If ICAR changes in the future, you only need to change the driver's constructor method, and do not need to modify any other code.

Summary

The dependency inversion principle is more difficult to understand than the six design principles. It is used in many frameworks, such as spring. The program world is the same as the real world. In other words, objects are also dependent. We cannot split all objects. In this case, the program cannot run, while maintaining dependencies, we need to reduce the coupling between objects. Being able to do well is indeed an art. For example, code 2 and code 3 are different practices, and the same results can be output in the end, code 3 is more complex than code 2, but if you consider future program extensions, it is obvious that code 3 is better than Code 2. As for the inversion, I think Mr. Qin Xiaobo is the simplest, which allows us to deeply understand the idea of inversion from a simple language.