Inversion of Control
Inversion of control is a relatively general design idea, not a specific implementation method, and is generally used to guide the design of the framework level. The "control" mentioned here refers to the control of the program execution flow, and the "reversal" refers to the programmer's own control of the execution of the entire program before the framework is used. After using the framework, the execution flow of the entire program is controlled by the framework. Control of the process is "reversed" from the programmer to the framework.
Dependency injection
Dependency injection and inversion of control are just the opposite, it is a specific coding technique. We don't create dependent class objects inside the class by means of new, but after the dependent class objects are created externally, they are passed (or injected) to the class for use through constructors, function parameters, etc.
Dependency injection framework
Through the extension points provided by the dependency injection framework, we simply configure all the required classes and their dependencies between classes, and then the framework can automatically create objects, manage the life cycle of objects, dependency injection, etc., which originally required programmers Things to do.
Dependence reversal principle
The principle of dependency inversion is also called the principle of dependency inversion. This principle is similar to inversion of control and is mainly used to guide the design of the framework level. High-level modules do not depend on low-level modules, they all rely on the same abstraction. Abstraction should not depend on specific implementation details. Specific implementation details depend on abstraction.
"High cohesion and loose coupling" is a very important design idea, which can effectively improve the readability and maintainability of the code, and reduce the scope of code changes caused by functional changes. "High cohesion" is used to guide the design of the class itself, and "loose coupling" is used to guide the design of the dependencies between classes. The so-called high cohesion means that similar functions should be placed in the same category, and dissimilar functions should not be placed in the same category. Similar functions are often modified at the same time, put in the same category, the modification will be more concentrated. The so-called loose coupling means that in the code, the dependencies between classes are simple and clear. Even if two classes have a dependency relationship, code changes in one class will not or rarely lead to code changes in the dependent class.
Dimit's rule: between classes that should not have direct dependencies, don't have dependencies; between classes that have dependencies, try to only rely on necessary interfaces. Dimit's law is to reduce the coupling between classes, so that the more independent the classes, the better. Each class should know less about the other parts of the system. Once a change occurs, there are fewer classes that need to understand the change.