IOC and DI

Understanding of the IOC and DI
Ioc:inversion of Control inversion
Di:dependency Injection Dependency Injection
Control inversion, from the literal point of view, is the control of the active and passive, and finally become passive.
As an example:
Your supervisor asks you to do one thing, and this time there are so many processes,
The Supervisor orders you to do things (this time the initiative is in charge, you are passive)
You get orders to do things (this time the subject is you, you are active, control is in your hands)
You finish things (this time the subject is still you, control is in your hands)
The Report Manager is done (the initiative is called in the supervisor's hand)
The entire process is completed once the IOC, as can be seen above, the basic idea of the IOC is control
The conversion process.
Example of a code:
If you have Class A, Class B, and a B is initialized within a, a method of invoking B Domethod
Public Class B
{
public void Domethod ()
{
Do somthing;
}
}
Public Class A
{
public void Excute ()
{
b b = new B ();
B.domethod ();
}
}
If you do this in the Main function:
A = new A ();
A.excute ();
Judging from these two lines of code, there is actually an IOC process, a-->b-->a, understanding the
The key point is the execution of the method B.domethod when the Excute is called inside a.
Understanding the IOC, let's take a look at DI.
From above a call B we can see that when initializing an instance of a A, you must also instantiate a B,
In other words, if there is no problem with B or B, a cannot be instantiated, which creates a dependency,
is A dependency B, this dependence is coupled from the design point of view, obviously it is unable to meet high cohesion
Low-coupling requirements. Decoupling is required at this time, but there are many ways of decoupling, and DI is the
One of the. Regardless of any decoupling method, it does not mean that A and B have no relation at all, but
The implementation of the relationship becomes obscure, less straightforward, but easy to implement, and easy to expand, without
Just like the code above, the new one B comes out.
So why do we always associate the IOC with DI? is because the basic idea of DI is the IOC,
And there is another way to embody the IOC thought, that is Service Locator, this method is good
Like the few involved.
DI, Dependency injection, literally means that dependency is implemented by an external injection.
This realizes decoupling, and DI is usually in three ways,
Constructor injection
Property Set Injection
Interface injection (I feel that interface injection is present in both of the two injection methods, and should not be independent
Out
The above explanation is only to allow us to have a perceptual understanding of the IOC and DI, then the IOC really
What is the problem of solving?
We talked so many active and passive questions, so what is the point of view?
So why do you take the initiative, and I am not active? This requires a reference, the reference
What is it? Is the container, in the container to reflect the active and passive.
In vernacular terms, it is the relationship between the container control program, rather than the traditional implementation, by the program code
Direct control. This is what is called the "inversion of Control" concept: control is transferred from the application code to
The external container, the transfer of control, is called "reversal", which is usually an interpretation of the IOC.
From the perspective of the container, active and passive, and by the container to control the relationship between the program, should be connected
, is a meaning.
The IOC is going to solve the problem of calling between programs, it should be a thought level thing, is
A center, like the conductor of a band, and the program is an instrument, through the command to coordinate a variety of instruments,
To play a beautiful music.
-------------I'm a gorgeous split line, here's a quote--------------------
A deep understanding of the IOC
What is the IoC? Inversion of control, or inversion, may be more appropriate for dependency injection.
IOC is the IOC, not a technology, like GoF, is a design pattern.
Interface driven Design interface driver, the interface driver has many advantages, can provide different
Flexible sub-class implementation, increase code stability and robustness, etc., but the interface must be implemented,
That is, the following statement will be executed sooner or later: ainterface a = new Ainterfaceimp (); Such a
, a coupling relationship arises, such as:
Class a{
Ainterface A;
A () {}
Amethod () {
A = new Ainterfaceimp ();
}
}
ClassA and Ainterfaceimp are dependencies, and if you want to use Ainterface's other real
Now you need to change the code. Of course, we can build a Factory to generate what we want based on conditions.
The specific implementation of ainterface, 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 does not change.
This coupling can be completely solved through IoC mode, which removes the coupling from the code and puts it in a unified
XML file, this dependency is formed by a container when needed, that is, the required interface
The implementation is injected into the class that needs it, which may be the source of the "dependency injection" argument.
IOC mode, the IOC container that implements the IOC mode is introduced in the system to
Manage object lifecycles, dependencies, and so on, so that application configuration and dependency specifications are
The actual application code is separated. One of the features is the use of the text of the accessory file for the application process
Configuration of the relationships between sequential components without having to re-modify and compile the specific code.
Currently more well-known IOC containers are: Pico Container, Avalon, Spring, JBoss,
Hivemind, EJB, and so on.
In several IOC containers above, the lightweight Pico Container, Avalon, Spring,
Hivemind, and so on, super-heavyweight has EJB, and half light half weight has the container has Jboss,jdon and so on.
The IOC model can be seen as a distillation of the factory model, where the IOC can be seen as a big factory,
It's just that the objects in this big factory are defined in the XML file, and then use Java
"Reflection" programming, generating the corresponding object based on the class name given in the XML. From the perspective of implementation, the IoC is
Generate code for objects that were previously written to die in the factory method, and are changed to be defined by an XML file, i.e.
Separate the plant from the object generation, which is designed to improve flexibility and maintainability.
The most basic Java technology in the IoC is "reflection" programming. Reflection is also a jerky noun,
Popular reflection is the generation of objects based on the given class name (string). This way of programming can be
Lets the object decide which object to build when it is built. The application of reflection is very extensive, like
Hibernate, String is used as the most basic technical means of "reflection".
In the past, the reflection programming method was 10 times slower than normal object generation, which may also
It was the reason why the reflection technology was not used in general. However, after SUN-improved optimization, the reflective
Way of generating objects and common object generation, the speed is not large (but still more than one times
The gap).
What are the IoC's greatest benefits? Because the object generation is defined in XML, so when we need to
It would be very simple to change the implementation subclass (generally such objects are actually some kind of interface),
Just modify the XML so that we can even implement a hot plug of the object (a bit like a USB connection
and SCIS hard drives).
What is the IoC's biggest drawback? (1) The steps to build an object become complicated (actually, the action
is very simple, for those who are not accustomed to this way, will feel somewhat awkward and not intuitive. (2)
Object generation is a loss of efficiency because it is programmed with reflection. But with respect to the IoC's improved maintenance
and flexibility, this loss is negligible unless the generation of an object is particularly efficient
High. (3) Lack of support for IDE refactoring operations, if you want to rename the class in Eclipse, you also need to
To go to the XML file manually to change, this seems to be the shortcoming of all the XML way.
On the implementation of IOC
The IOC focuses on how services (or application parts) are defined and how they should locate them according to
Other services. Typically, a container or a positioning framework is used to obtain the separation of definitions and positioning,
Or positioning framework is responsible for:
Save a collection of available services
Provides a way to bind various parts together with the services they depend on
Provides a way for application code to request a configured object (for example, one of all dependencies satisfies
Object), which ensures that all related services required by the object are available.
The existing framework actually performs the binding between services and parts using a framework of the following three basic technologies:
Type 1 (interface-based): A service object needs to implement a dedicated interface that provides a
Object that can be used to find dependencies (other services) from this object. Early use of container Excalibur
This mode.
Type 2 (Setter-based): Specifies the service object through the JavaBean property (setter method)
Service. Hivemind and Spring take this approach.
Type 3 (constructor-based): Specifies the service for the serviced object through the parameters of the constructor.
Picocontainer only use this method. Hivemind and Spring also use this approach.
-----------------ornate split Line, reference end-------------------------Interface driven Design interface driver
There are many benefits to interface drivers that can provide different, flexible sub-class implementations that increase code stability and robustness
And so on, but 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 arises.
Such as:
Class A
{
Ainterface A;
A () {}
Amethod ()
{
A = new Ainterfaceimp ();
}
}
ClassA and Ainterfaceimp are dependencies, and if you want to use Ainterface's other real
Now you need to change the code.
Of course we can build a Factory to generate the specific implementation of the desired ainterface based on the conditions,
That
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 does not change.
This coupling can be completely solved through IoC mode, which removes the coupling from the code and puts it in a unified
XML file, this dependency is formed by a container when needed, that is, the required interface
The implementation is injected into the class that needs it, which may be the source of the "dependency injection" argument.
IOC-mode system, by introducing IOC containers that implement IOC mode, the IOC container can be used to manage
such as the lifecycle of the image, dependencies, etc., so that the configuration and dependency specifications of the application and the actual
The application code is separated. One feature is the application component through a text configuration file
Instead of having to re-modify and compile the specific code.
Currently more well-known IOC containers are: Pico Container, Avalon, Spring, JBoss, Hivemind,
EJB, and so on. Among them, the lightweight has Pico Container, Avalon, Spring, hivemind, etc.,
The super-heavyweight has the EJB, but the half light half weight has the container to have the Jboss,jdon and so on.
The IOC model can be seen as a distillation of the factory model, where the IOC can be seen as a big factory, with no
The objects to be generated in this large factory are defined in the XML file, and then use the Java
"Reflection" programming, generating the corresponding object based on the class name given in the XML. From the perspective of implementation, the IoC is
The object that was previously written dead in the factory method generates code that is changed to be defined by an XML file, which is the
The plant and object generation are separated independently, with the aim of increasing flexibility and maintainability.
The most basic Java technology in the IoC is "reflection" programming. Reflection is also a jerky noun, popular
Reflection is the generation of objects based on the given class name (string). This way of programming allows you to
The image is generated to determine which object to build. The application of reflection is very extensive, like Hibernate,
In String, "reflection" is used as the most basic technical means.
What are the IoC's greatest benefits? Because the object generation is defined in XML, so when we need to change
A subclass of implementation will become very simple (generally such objects are real to some kind of interface), only
You can modify the XML.

IOC and DI