A detailed explanation of the principle of dependency inversion--seven large object oriented design principles (3)

dependency Inversion principle Source:

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.

The dependency inversion principle (dependence inversion principle) is a program that relies on an abstract interface and does not rely on a specific implementation. Simply speaking, it requires programming the abstraction and not programming the implementation, thus reducing the coupling between the client and the implementation module.

A. High-level modules should not rely on low-level modules, both of which should rely on their abstraction. Abstractions should not rely on detail, and details should rely on abstraction. (Details: That is, the specific implementation class, implement the interface or inherit the class generated by the abstract class, can be directly instantiated by keyword new.) ）

B. An abstract class or interface that cannot be instantiated.

Dependency inversion principle starting point: In contrast to the variability of detail, abstract things are more stable. The structure built on the basis of abstraction is more stable than the structure based on detail. Through abstraction (abstract class or interface), the implementation of each class or module is independent, and does not affect each other, and the loose coupling between modules is realized. 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. This is also the basis of the principle of opening and closing.

three ways to implement the dependency inversion principle:

(1). Pass the dependent object through the constructor function;

For example, the parameters to be passed in the constructor are implemented in the form of an abstract class or interface.

(2). Passing the dependent object by setter method;

That is, the parameter in our set method is an abstract class or interface to implement the transitive dependency object.

(3). Interface declaration implements dependent objects, also called interface injection;

That is, the parameter is an abstract class or interface in the function declaration to implement the transitive dependent object, thus achieving the purpose of directly using the dependent object.

Can be summed up as interface transfer, construction method delivery and setter method delivery. The core of the dependency inversion principle is that we should interface programming, understand the interface programming, and understand the dependency inversion;

examples of dependency inversion principles:

In our financial system development, we often need to transfer K-line or time-sharing data to other files or reports, so data format conversion is required. The method of calling the data format conversion class in the customer data manipulation class implements the format conversion and the database insert operation, and the initial design scheme structure is shown in Figure 1:

When coding to implement the structure shown in Figure 1, we found a very serious problem with the design, because the data source is not necessarily the same each time the data is converted, so you need to replace the data conversion class, such as sometimes the need to change the klinedataconvertor to Mindataconvertor, At this point, you need to modify the source code of Customerdao, and in the introduction and use of new data conversion classes also have to modify the source code of Customerdao, the system is poor scalability, violates the open and closed principle, now need to refactor the scheme.

Because Customerdao is programmed for specific data transformation classes, it is necessary to modify the Customerdao source code when adding new data conversion classes or replacing data conversion classes. We can solve this problem by introducing the abstract Data transformation class, after introducing the abstract Data Transformation class Dataconvertor, Customerdao to the abstract class Dataconvertor programming, but stores the concrete Data transformation class name in the configuration file, conforms to the dependency reversal principle. According to the Richter substitution principle, when the program is run, the specific Data transformation class object will replace the Dataconvertor type object, and the program will not have any problems. Replace the specific data conversion class without modifying the source code, only need to modify the configuration file, if you need to add new specific data conversion classes, as long as the additional data conversion class as a subclass of Dataconvertor and modify the download file structure, the original code need not make any changes to meet the opening and closing principles. The reconstructed structure is shown in Figure 2:

In the course of the above reconstruction, we use the open and closed principle, the Richter substitution principle and the reliance on the reverse principle, in most cases, these three design principles will appear at the same time, the opening and closing principle is the goal, the Richter substitution principle is the basis, relying on the inverted principle is the means, they complement each other, mutually complementary, the It's just a different point of view when analyzing the problem.

dependency Inversion Principle use summary:

(1). Lower-level modules should have abstract classes or interfaces as much as possible, or both.

(2). The declaring type of a variable is as much an abstract class or interface as possible.

(3). Follow the Richter substitution principle when using inheritance.