Glossary
Dependency: describes the relationship between model elements. For example, if Class A calls Class B, Class A depends on Class B.
Coupling: A description of the relationship between model elements. For example, if Class A calls Class B or Class B calls Class A, Class A is coupled with Class B.
Coupling Degree: quantitative description of the degree of dependency between model elements.
Control: describes the relationship between model elements. For example, if Class A calls Class B, Class A controls Class B.
Introduction
The architecture design objects are generally class libraries, frameworks, and applications. In addition to the relationship design between modules (classes) of the class libraries, frameworks, and applications, Its tasks also include the design of the relationship among class libraries, frameworks, and applications. Dependency inversion, control inversion, and dependency injection are common design patterns.
Dependency inversion, control inversion, and dependency injection are basically the same as those of the target, that is, decoupling and eliminating dependencies through abstract interfaces.
Dependency inversion
From literal understanding, dependency inversion often leads to the cloud, which can be well eliminated by understanding its historical origins. In the era of structure-oriented programming, architects often adopt top-down design models. First, they design upper-layer modules and then lower-layer modules. As a result, upper-layer modules are heavily dependent on lower-layer modules, A single change in the lower-layer module will lead to an upper-layer earthquake. In the era of object-oriented programming, architects use objects to design and decouple dependencies between layers through abstract interfaces. In order to distinguish from the structure-oriented design patterns and reflect the advantages of object-oriented, in order to get the favor of others, the new design pattern is put up with a name of dependency inversion.
The core idea of dependency inversion is dependent on abstraction.
The principle of dependency inversion is that the upper-layer module does not depend on the lower-layer module, but relies on an abstract interface. The upper-layer module calls the interface and the lower-layer module implements the interface. Taking the class library and application as an example, we abstract the functions that the application needs to call into a set of interfaces, and then the class library implements these interfaces, then the application can use any class library that implements this interface to decouple it from the class library.
Control reversal
The history of control inversion is similar to that of dependency inversion. Although a class library is referenced in a previously designed application, everything is under the control of the application. Later, according to different scenarios of the application, people designed the corresponding framework. After the framework was built, when the application was designed again, it became a design that added custom behavior to the framework, the control is transferred to the framework, so the control is reversed.
Control inversion is a specific implementation of dependency inversion. It emphasizes the Dependency inversion of control processes and is a required mode for framework design. Framework is designed based on the Dependency inversion mode: for uncertain parts of the framework, the Framework abstracts a set of interfaces and relies on these interfaces for implementation. Applications implement these interfaces.
Dependency Injection
Dependency injection is a specific implementation of dependency inversion and a common mode for designing class libraries. Classes in the class library are designed based on the dependency mode: Some Classes depend on interfaces rather than specific implementations. The caller can pass in the specific implementation classes of these interfaces during calls.
. NET is widely used in this mode, such as the streamreader class. When using streamreader, You need to instantiate a stream or its derived class and pass it to the streamreader constructor before using this class.
Disadvantages
The foundation of dependency inversion is that the abstraction is stable. Of course, we can implement good abstraction for things we already know, but it is difficult to ensure the stability of abstraction for things that we have not yet understood, such as user requirements. Therefore, once this assumption of abstract stability is not true, dependency inversion may not take advantage of it, but may become a burden.
From: http://blog.sina.com.cn/s/blog_554634270100oo2k.html