What the IOC is (turn from phpxiaoxin)

What the IOC is (transferred from Phpxiaoxin)
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, 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 (); 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 another implementation of ainterface, 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, 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 the IOC pattern, which removes the coupling from the code and puts it into a unified XML file, which is formed by a container when needed, that is, injecting the required interface implementation into the class that needs it, which may be the source of the "dependency injection" argument.
In IOC mode, the IOC container can be used to manage the object's life cycle, dependencies, etc. by introducing an IOC container that implements IOC mode, which separates the application configuration and dependency specifications from the actual application code. One feature is the configuration of the interaction between application components through the text's accessory file without having to re-modify and compile the specific code.
Currently more well-known IOC containers are: Pico Container, Avalon, Spring, JBoss, Hivemind, EJB, etc.
In the above several IOC containers, the lightweight has Pico Container, Avalon, Spring, Hivemind, and so on, super-heavyweight with EJB, and semi-light semi-heavy 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 large factory, except that the objects to be generated in this large factory are defined in the XML file, and then, using the "reflection" programming of Java, the corresponding objects are generated based on the class names given in the XML. In terms of implementation, the IOC generates code for objects previously written in the factory method, which is changed to be defined by an XML file, that is, separating the factory from the object generation, 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, and popular reflection is the generation of objects based on the given class name (string). This way of programming allows an object to decide which object to build when it is built. The application of reflection is very extensive, like Hibernate, string is "reflection" as the most basic technical means.
In the past, the reflection programming method was 10 times slower than normal object generation, which may be why the reflection technology was not used in general. However, after Sun improved optimization, the reflection mode generated objects and the usual object generation method, the speed has been very different (but still more than a gap).
What are the IOC's greatest benefits? Because the object generation is defined in XML, it becomes very simple when we need to change an implementation subclass (generally such objects are real to some kind of interface), as long as the XML is modified so that we can even implement the object's HotPlug (a bit like the USB interface and the SCIS hard drive).
What is the IOC's biggest drawback? (1) The steps to generate an object become complex (actually on the operation is quite simple), for those who are not accustomed to this way, will feel somewhat awkward and not intuitive. (2) object generation because of the use of reflection programming, the efficiency of some loss. But this loss is negligible relative to the increased maintainability and flexibility of the IOC, unless the generation of an object is particularly demanding in terms of efficiency. (3) Lack of support for IDE refactoring operations, if you want to rename the class in Eclipse, then you need to go to the XML file manually to change, which seems to be the shortcoming of all the XML way.

