Dependency inversion (DIP) vs. Dependency Injection (DI)

The dependency inversion principle (Dependency inversion Principle) provides us with a way to reduce the coupling between modules, and the dependency injection (Dependency injection) is a concrete implementation method.

Dependency Inversion principle:

The previous article on software design principles has already mentioned the "dependency inversion principle" (Dependency inversion Principle), which is mainly to reduce the "coupling degree" between modules and modules, and advocates that the module does not have a direct dependency between modules, namely: High-level modules should not be directly dependent on low-level modules, and high-rise modules and low-rise modules should be dependent on an abstraction layer. If you now have a class manager that needs to log error logs when dealing with a task, we can write code like this:

View Code

As shown in the code above, the FileLogger class is responsible for saving the error log to a file, the manager class defines a logger class object, specifically responsible for logging the error log, the "High-level module" manager class in this code is directly dependent on the "low-layer module" FileLogger, If we now need to send the error log to someone else via email, or send it to another module, we have to modify the manager Class code.

The dependency inversion principle suggests that the manager class should not be directly dependent on the FileLogger class, but should rely on an abstraction layer (interface layer), so the original code should write:

View Code

As shown in the code above, we abstract the logic of logging error logs out of a Ilog interface, the manager class no longer relies on any specific class, but relies on the Ilog interface, and we can implement a variety of logging classes according to the Ilog interface, If FileLogger saves the log to a file, Emaillogger sends the log as a message to someone, Notifylogger notifies the program of other modules of the error message. In this way, the flexibility of the entire code has increased significantly, if we need to save the log to a file, direct use of FileLogger, if we want to send the log as a message to others, directly use Emaillogger and so on. Show dependencies before and after the inversion occurs:

Dependency Injection:

The manager class above is no longer directly dependent on any specific logging type, but in essence, we create the log class object or inside the manager (catch), if we want to log in a different way, or the manager class code, there is no way to Can we change the way we log records without having to change the manager's code? Of course there is, "dependency injection" is the specific solution to this problem, we have three ways to make two types of dependencies:

(1) Construction injection (Constructor injection)

When we create the manager object, we pass the log object as a construction parameter to the newly created Manager object, assuming that the manager has a construction method with the Ilog type parameter, such as:

View Code

So, when we create the manager object, we write the code:

Manager m = new manager (new FileLogger ());

Manager m = new manager (new Emaillogger ());

Manager m = new manager (new Notifylogger ());

Obviously, this kind of logging is always the same and works for the manager for a lifetime.

(2) Method injection (methods injection)

Add a Ilog parameter to each method in the manager class that requires logging, such as the Manager.dosomething method, which is redefined as:

View Code

Then when we use the manager later, each invocation of the method should provide it with a log object, such as:

Manager m = new manager ();

M.dosomething (New FileLogger ());

M.dosomething (New Emaillogger ());

M.dosomething (New Notifylogger ());

This way of logging is only valid for the current method, and each invocation method can be different.

(3) Attribute injection (property injection)

Exposes a property in the manager class to set the logging object, Mananger this definition:

View Code

After we use Mananger, we can change its logging mode at any time:

Mananger m = new Manager ();

M.logger = new FileLogger ();

M.logger = new Emaillogger ();

M.logger = new Notifylogger ();

In this way, we can switch the logging method at any time, with flexibility between "construct injection" and "Method injection".

The above three dependency injection methods can be mixed, that is, you can define a parameter with the Ilog type for the manager class, or you can define a property of type Ilog, or add a ilog type parameter for each method.

　　Note:

"1" in . NET , the "abstraction layer" can be implemented without using interface interface , but instead using the delegate directly , for example, when we use the filestream.beginread method, we give it a AsyncCallback callback parameter, which in fact belongs to the " method to inject "one.

the "2" type and type can not completely lose the dependency relationship, how to make this kind of non-essential dependence is weaker, is the software design of a profound knowledge.

Dependency inversion (DIP) vs. Dependency Injection (DI)