IOC Inversion of control inversion
DI Dependency Injection Dependency Injection
To understand these two concepts, let's first clarify the following questions: Who are the participants? Dependence: Who depends on who. Why you need to rely on. Inject: who injects into who. What to inject. Control reversal: Who controls who. Control what. Why is it called inversion (there should be a positive turn if there is a reversal). Dependency injection and control inversion are the same concepts.
Here is a brief answer to the above questions, to understand these problems, Ioc/di also understand.
(1) Who are the participants:
There are generally three-party participants, one is an object, one is a Ioc/di container, and the other is an external resource for an object.
And the noun to explain, an object refers to an arbitrary, ordinary Java object; The Ioc/di container is simply a framework program used to implement the Ioc/di function, and the object's external resources refer to what the object needs, but it is obtained from outside the object, collectively referred to as resources, such as: other objects required by the object, or the file resources required by the object, etc.
(2) who depends on who:
Of course, a container that relies on Ioc/di for an object.
(3) Why you need to rely on:
Objects require IOC/DI containers to provide the external resources required by the object
(4) who is injected into whom:
It's obvious that Ioc/di's container injects an object.
(5) Exactly what to inject:
is the external resources needed to inject an object
(6) Who controls who:
Of course, it's Ioc/di's container to control the object.
(7) Control what:
The main control is the creation of object instances
(8) Why reverse is called:
The reversal is relative to the positive, then what is positive? Consider the general application, what would you do if you were to use C in a. Of course, it is directly to create a C object, that is, in class A to take the initiative to obtain the required external resource C, this situation is called forward. So what is the reverse? Is that class A no longer takes the initiative to acquire C, but passively waits, waits for the Ioc/di container to get an instance of C, and then injects the reverse into Class A.
Using the legend to illustrate, first look at the time without Ioc/di, the general Class A uses the C class diagram, as shown in Figure 7:
Figure 7 General a uses C schematic
When a Ioc/di container is available, Class A no longer takes the initiative to create C, as shown in Figure 8:
Figure 8 Class A is no longer actively creating C
Instead, wait for the Ioc/di container to get an instance of C, and then inject the reverse into the Class A, as shown in Figure 9:
Figure 9 schematic diagram of the program structure with Ioc/di container
(9) Dependency injection and control inversion are the same concepts.
According to the above, it should be seen that dependency injection and inversion of control are different descriptions of the same thing, and in one way or another, they describe different angles. Dependency injection is described from an application perspective, where dependency injection can be described as the complete point: The application relies on the container to create and inject the external resources it needs, while control inversion is described from the container's perspective, describing the complete point: container control applications, the external resources required by the container to inject the application into the application in reverse.
(10) Summary:
In fact, the biggest change Ioc/di to the programming is not from the code, but from the thought, has occurred "master-slave Transposition" change. The application was originally the boss, to get what resources are active attack, but in Ioc/di thought, the application becomes passive, passively wait for the Ioc/di container to create and inject the resources it needs.
Such a small change is actually a big step forward in programming thinking, which effectively separates the object and the external resources it needs, makes them loosely coupled, facilitates functional reuse, and, more importantly, makes the entire architecture of the program very flexible.
(11) The process of the dependency injection mechanism is then demonstrated.
Code 2 business object to be injected Content.java
Package com.zj.ioc.di.ctor; import com.zj.ioc.di.Content; Public class mybusiness { private Content mycontent; Public MyBusiness (content content) {mycontent = content; } public void dobusiness () {mycontent. Busniesscontent (); } public void doanotherbusiness () {mycontent. Anotherbusniesscontent (); } } |
The Mybusniess class shows a business component whose implementation requires the injection of object Content. Code 3, code 4, code 5, 6 demonstrate the construction of sub-injection (Constructor injection), set value injection (Setter injection) and interface injection (Interface injection) three ways.
Code 3 Construction Sub-injection (Constructor injection) Mybusiness.java
Package com.zj.ioc.di.ctor; Import com.zj.ioc.di.Content; Public class mybusiness { Private Content mycontent; Public mybusiness (content content) { mycontent = content; } public void dobusiness () { mycontent. Busniesscontent (); } public void doanotherbusiness () { mycontent. Anotherbusniesscontent (); }} |
Code 4 Set Value injection (Setter injection) Mybusiness.java
Package com.zj.ioc.di.iface; import com.zj.ioc.di.Content; Public Interface incontent { void createcontent (content content);} |
Code 5 Setting the injection interface Incontent.java
package com.zj.ioc.di.iface; import com.zj.ioc.di.Content; Public Interface incontent { void createcontent (content content);}
|
Code 6
Interface Injection (Interface injection) Mybusiness.java
Package com.zj.ioc.di.iface; Import com.zj.ioc.di.Content; Public class MyBusiness implements incontent{ Private Content mycontent; public void createcontent (content content) { mycontent = content; } public void dobusniess () { mycontent. Busniesscontent (); } public void doanotherbusniess () { mycontent. Anotherbusniesscontent (); }} |