How to deeply understand dip, IOC, DI and IoC containers

Objective

For most of the dishes, are there any moments when you hear Daniel talking about dips, IOC, DI, and IOC containers? In fact, these "tall" nouns, understanding is not so difficult, the key is to get started. As long as we get started, and then gradually, in time, naturally.

Well, let's start with some of these concepts.

dependency Inversion principle (DIP): A principle of software architecture design (abstract concept).

control Reversal (IoC): a way of inverting flows, dependencies, and interfaces (the specific way in which a dip is implemented).

Dependency Injection (DI): An implementation of the IOC, which is used to reverse reliance (the specific way the IOC implements it).

IOC container: A Dependency Injection framework for mapping dependencies, managing object creation and Lifetime (DI framework).

Oh! Maybe you're hurting your brains for these unfamiliar concepts. But it doesn't matter, next I will for you one by one miju this one of the mystery.

Dependency inversion principle (DIP)

Before we talk about concepts, let's look at an example of life.

Figure 1 ATM and bank card

I believe most of the friends who have taken money are deeply touched, as long as there is a card, any bank ATM can withdraw money. In this scenario, ATM is the equivalent of a high-level module, while a bank card is the equivalent of a low-level module. ATM defines a socket (interface) that is used by all bank card inserts. That is, ATM does not depend on what kind of bank card is in particular. It only needs to define the specification parameters (interface) of the bank card, and all the bank cards that implement this specification can be used on ATM. Real life is so, software development is even more so. The dependency inversion principle, which transforms dependencies, does not depend on the implementation of low-level modules, and the low-level modules rely on interfaces defined by high-level modules . Colloquially speaking, is the high-level module to define the interface, the low-level module is responsible for implementation.

Bob Martins's definition of dip:

High-level modules should not rely on low-level modules, both of which should depend on abstraction.

Abstractions should not be dependent on implementations, and implementations should rely on abstractions.

If the case of life is not sufficient to illustrate the importance of the principle of dependency inversion, then we will use the software development scenario to understand why the dependency inversion principle is used.

Scene one relies on no inversion (low-level module definition interface, high-level module is responsible for implementation)

From the above illustration, we find that the class of the high-level module relies on the interfaces of the low-level modules. Therefore, the low-level modules need to take into account all the interfaces. If a new low-level module class appears, the high-level module needs to modify the code to implement the new low-level module interface. In this way, the principle of open closure is undermined.