Dependency inversion, control inversion and dependency injection of architecture design

noun explanation

dependency: A description of the relationship between model elements. For example, Class A calls Class B, so we say Class A relies on Class B.

coupling: A description of the relationship between model elements. For example, Class A calls Class B or class B calls Class A, so we say that class A has a coupling relationship with Class B.

Coupling degree: A quantitative description of the degree of dependency between model elements.

control: A description of the relationship between a model element. For example, Class A calls Class B, so we say Class A controls Class B.

Introduction

Schema design objects are typically class libraries, frameworks, and applications. In addition to the relational design of class libraries, frameworks, and application modules (classes), it also includes the design of relationships between class libraries, frameworks, and applications. However, dependency inversion, inversion of control and dependency injection are the common design patterns.

Dependency inversion, inversion of control, and dependency injection have the same meanings and goals, i.e. decoupling and eliminating dependencies through abstract interfaces.

Dependency inversion

The literal understanding of dependency inversion is often unintelligible, and the misunderstanding can be well eliminated by understanding its historical origins. In the era of structural programming, architecture designers often use top-down design patterns, first design the upper module, and then design the lower module, so that the layer decomposition, resulting in the upper module is heavily dependent on the lower module, the lower module changes will lead to the upper earthquake. In the era of object-oriented programming, architecture designers use objects to design, decoupling the dependencies between layers through an abstract interface, in order to separate from the structure-oriented design pattern, and to embody the advantages of object-oriented, but also for the sake of grandstanding, it gives the new design pattern a dependency inversion name.

The core idea of dependency inversion is to rely on abstraction.

The principle of dependency inversion is that the upper module does not depend on the lower module, but relies on a set of abstract interfaces, the upper module calls the interface, and the lower module implements the interface. In the case of class libraries and applications, where we abstract the functions that the application needs to invoke into a set of interfaces, and then implement this set of interfaces by the class library, the application can decouple from the class library by using any class library that implements the interface.

Control reversal

The origin of control inversion is similar to dependency inversion, where the application was previously designed, although it would refer to the class library, but everything was in the control of the application. Later, according to the different scenarios of the application, people designed the corresponding framework, after the framework, and then design the application, it becomes the framework to add custom behavior of the design, control to the frame hand, so that control reversed.

Control inversion is a concrete implementation of dependency inversion, emphasizing the dependency inversion of control process and the necessary mode of frame design. The framework is based on a dependency inversion pattern design: For an indeterminate part of the framework, the framework abstracts out a set of interfaces and relies on this set of interfaces for implementation, and the application implements this set of interfaces.

Dependency Injection

Dependency injection is also a concrete implementation of dependency inversion, which is a common pattern of class library design. Classes in a class library are based on a dependency pattern design: A class relies on an interface rather than a specific implementation, which is passed on by the caller to the specific implementation class of those interfaces.

. 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, passed to the StreamReader constructor, and then can use the method of the class.

Ills

The basis of dependency inversion is the assumption that abstractions are stable. Of course we can achieve good abstraction for what we already know, but it is difficult to guarantee this abstract stability for things that are not yet known, such as user requirements. Therefore, once this assumption of abstract stability is not established, then dependency inversion not only can not play an advantage, but may become a burden.

Original article from: http://blog.sina.com.cn/s/blog_554634270100oo2k.html

Dependency inversion, control inversion and dependency injection of architecture design