Understanding of IOC and Di

IOC: inversion of control Inversion

DI: dependency injection dependency Injection

Control reversal, literally, means that control is passive and active, and finally passive.

For example:

Your supervisor asks you to do one thing. There are several processes at this time,

The supervisor instructs you to do things (at this time, the initiative is in charge, and you are passive)

You receive commands to do things (at this time, the theme is you, you are active, and control is in your hands)

You have done things (at this time, the theme is still you, and control is in your hands)

Report the supervisor to finish the task (the initiative is handed over to the supervisor)

The entire process above completes an IOC. From the above, we can see that the basic idea of IOC is the conversion process of control.

For exampleCodeExample:

If there is Class A and Class B, a Class B will be initialized within a, and a method of domethod of B will be called.

Public Class B
{
Public   Void Domethod ()
{
// Do somthing;
}
}

PublicClass
{
Public VoidExcute ()
{
B= NewB ();
B. domethod ();
}
}

Run the following command in the main function:

A =   New A ();
A. excute ();

From the two lines of code, there is actually an IOC process. A --> B --> A, the key point of understanding is that when a calls excute internally, method B. domethod execution.

After understanding IOC, let's take a look at di.

We can see from the above a call to B that a B must be instantiated when initializing an instance of A. That is to say, if there is no problem with B or B, a cannot be instantiated, this produces a dependency, that is, a depends on B. From the design perspective, this dependency is coupling. Obviously, it cannot meet the requirements of high cohesion and low coupling. At this time, decoupling is required. Of course, there are many decoupling methods, and Di is one of them. No matter whether a decoupling method is used, it does not mean that a and B are completely irrelevant. Instead, the implementation of this relationship is concealed, not so direct, but easy to implement and easy to expand, unlike the code above, a new B is provided directly.

Why do we always associate IOC with Di? This is because the basic idea of DI is IOC, and there is another way to embody IOC, that is, service locator, which seems to involve very little.

Di, dependency injection. It can be seen from the literal meaning that dependency is implemented through external injection. This achieves decoupling, and there are usually three di methods,

Constructor Injection

Property configurator Injection

Interface injection (I feel that interface injection exists in the two injection methods at the same time, instead of being independent)

The above is just to give us a perceptual understanding of IOC and Di. What is the real problem solved by IOC?

We have talked about so many active and passive problems. From what perspective do we look at this problem?

Why are you active, but I am not active? This requires a reference object. What is this reference object? Is the container, in the container to reflect active and passive.

In the vernacular, container control is used.ProgramIn non-traditional implementations, programs are directly controlled by code. This is also the concept of "control reversal": control is transferred from application code to external containers. The transfer of control is called "reversal", which is usually an explanation of IOC.

From the perspective of containers, the relationship between active and passive programs and the control programs of containers should be the same.

IOC is to solve a problem of calling between programs. It should be an ideological thing, a center, like a band's command, and a program is an instrument, coordinates various instruments through command to play beautiful music.

 

The following text reference: http://www.cnblogs.com/gooddasenlin/archive/2009/03/02/1401631.html

Interface driven design interface driver

The interface driver has many advantages: it can provide different flexible sub-class implementations and increase code stability and robustness. However, the interface must be implemented, that is, the following statement will be executed sooner or later: ainterface A = new ainterfaceimp (); in this way, the coupling relationship is generated.

For example:

Class
{
Ainterface;
A (){}
Amethod ()
{
A =   New Ainterfaceimp ();
}
}

 

Classa and ainterfaceimp are dependencies. To use another ainterface implementation, you need to change the code.

Of course, we can create a factory to generate the specific implementation of the desired ainterface according to the conditions, namely:

Interfaceimplfactory
{
Ainterface create (Object condition)
{
If (Condition = Conda)
{
Return   New Ainterfaceimpa ();
}
Elseif (Condition = Condb)
{
Return   New Ainterfaceimpb ();
}
Else
{
Return   New Ainterfaceimp ();
}
}
}

 

On the surface, the above problems are mitigated to some extent, but in essence this code coupling has not changed.

This coupling can be completely solved through the IOC mode, which removes the coupling from the code and puts it in a unified XML file. This dependency is formed by a container as needed, that is, inject the required interface implementation into the class that requires it. This may be the source of the "dependency injection" statement.

In the IOC mode system, IOC containers can be used to manage object lifecycles and Dependencies by introducing IOC containers, thus, application configuration and dependency specifications are separated from the actual application code. One feature is to configure the relationship between application components through the text configuration file, instead of re-modifying and compiling specific code.

Currently, well-known IOC containers include Pico container, avron, spring, JBoss, hivemind, and EJB. Among them, the lightweight ones include Pico container, aveon, spring, hivemind, etc. The super heavyweight ones include EJB, while the half-light and half-heavy ones include JBoss and jdon.

The IOC mode can be seen as the sublimation of the factory mode, and IOC can be seen as a large factory, but the objects to be generated in this large factory are defined in the XML file, then, use Java's "reflection" programming to generate the corresponding object based on the class name given in XML. From the implementation point of view, IOC is to generate code for the previously written object in the factory method, which is defined by the XML file, that is, to separate the factory and object generation, the purpose is to improve flexibility and maintainability.

The most basic Java Technology in IOC is reflection programming. Reflection is a natural term. In general, reflection is used to generate an object based on the given class name (string. This programming method allows an object to decide which object to generate when it is generated. Reflection is widely used. For example, Hibernate and string use reflection as the most basic technical means.

What are the biggest benefits of IOC? Because the object generation is defined in XML, when we need to change an implementation subclass, it will become very simple (generally, such an object is actually an interface ), you only need to modify the XML.