This article is a summary of wang Zhengda’s the Beauty of Design Patterns
Pre-inversion of Control (IOC)
Inversion Of Control is an Inversion Of Control.
The framework provides an extensible code skeleton for assembling objects and managing the entire execution flow. When programmers use the framework to develop, they only need to add the code related to their business to the reserved extension points, and then they can use the framework to drive the execution of the whole program flow. “Control” refers to the control over the flow of program execution, while “inversion” refers to the control of the entire program execution by the programmer himself before using the framework. After using the framework, the execution flow of the whole program can be controlled by the framework. Control of the process is “flipped” from the programmer to the framework.
Inversion of control is not a specific implementation technique, but rather a general design idea that is used to guide frame-level design.
Pre – Dependency Injection (DI)
Dependency injection, as opposed to inversion of control, is a specific programming technique. Dependency Injection (DI) is a Dependency Injection. There’s a nice way to put it: DEPENDENCY injection is a $25 concept that’s actually worth five cents. That said, the concept sounds fancy, but it’s actually pretty simple to understand and apply. Instead of creating a dependent object inside a class using a new() method, we pass (or inject) the dependent object into the class using constructors, function parameters, etc.
By passing in dependent class objects through dependency injection, code extensibility is improved and dependent classes can be replaced flexibly.
Pre-dependency Injection Framework (DI Framework)
In real software development, some projects may involve dozens, hundreds, or even hundreds of classes, and the creation and dependency injection of class objects can become very complex. If this part of the work is to rely on programmers to write their own code to complete, prone to error and development costs are relatively high. The object creation and dependency work itself has nothing to do with the specific business, we can be abstracted into a framework to automate, this framework is “dependency injection framework”.
With the extension points provided by the dependency injection framework, we simply configure all the class objects that need to be created, and the dependencies between classes, so that the framework can automatically create objects, manage the life cycle of objects, dependency injection, and other things that should be done by programmers.
Dependency Inversion Principle (DIP)
Dependency Inversion is a Dependency Inversion Principle (DIP). The principle is described in English as follows:
High-level modules shouldn’t depend on low-level moduled.Both modules should depend on abstractions.In addition, abstractions shouldn’t depend on details.Details depend on abstractions.
High-level modules do not depend on low-level modules. High level modules and low level modules should depend on each other through abstracttions. In addition, abstracttions should not depend on details; details depend on abstractions.
The so-called division of high-level module and low-level module, simply speaking, in the call chain, the caller belongs to the high-level, the called belongs to the low-level. In actual business code development, there is no problem with high-level modules relying on low-level modules. In fact, this principle is mainly used to guide design at the framework level, similar to inversion of control.
For example:
Tomcat is a container for running Java Web applications. The Web application code we wrote only needs to be deployed under the Tomcat container to be invoked and executed by the Tomcat container. According to the previous classification, Tomcat is a high-level module, and the Web application we wrote is a low-level module. There is no direct dependency between Tomcat and application code; both rely on the same abstraction, the Servlet specification. The Servlet specification does not depend on the implementation details of specific Tomcat containers and applications, which depend on the Servlet specification.