What is IOC? Inversion of control, that is, reverse control, may be more suitable for dependency injection. IOC is IOC, not a technology. Like gof, IOC is a design model.
The interface driven design interface driver has many advantages. It can provide different flexible subclass implementations and add Code Stability and robustness, 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 is generated, for example, Class A {ainterface A; A () {} amethod () {A = new ainterfaceimp () ;}} classa and ainterfaceimp are dependencies, if you want to use another ainterface implementation, you need to change the code. Of course, we can create a factory to generate the desired ainterface implementation based on the conditions, that is, 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 IOC mode, IOC containers can be used to manage object lifecycles and Dependencies by introducing IOC containers. Program The configuration and dependency specifications are separated from the actual application code. One feature is to configure the relationship between application components through the text accessory file, instead of modifying and compiling the specific code.
Currently, well-known IOC containers include Pico container, avron, spring, JBoss, hivemind, and EJB.
Among the above several IOC containers, the lightweight ones include Pico container, aveon, spring, hivemind and so on. 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.
In the past, the reflection programming method was 10 times slower than the normal object generation method, which may be why the reflection technology was not widely used at the time. However, after Sun's optimization, the reflection method generates the object and the normal object generation method, and the speed is not much different (but there is still a gap more than doubled ).
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, so that we can even implement the Hot Plug-in of the object (a bit like the USB interface and scis hard disk ).
What are the biggest disadvantages of IOC? (1) The process of generating an object becomes complicated (in fact, the operation is quite simple). For those who are not used to this method, they will feel awkward and inintuitive. (2) object generation is inefficient because reflection programming is used. However, this loss is negligible compared with IOC's increased maintainability and flexibility, unless the generation of an object requires a particularly high efficiency. (3) There is a lack of support for IDE refactoring operations. If you want to rename the class in eclipse, you still need to manually change it in the XML file, this seems to be the shortcoming of all XML methods.
IOC implementation
IOC focuses on how services (or application components) are defined and how they should locate other services they depend on. Usually, a container or positioning framework is used to obtain the separation of definition and positioning. The container or positioning framework is responsible:
- Save a set of available services
- You can bind components to the services on which they depend.
- Provides a method for application code to request configured objects (for example, an object with all dependencies satisfied ), this method ensures that all related services required by the object are available.
The existing framework actually uses the following three basic technologies to implement binding between services and components:
- type 1 (based on interfaces): a service-able object must implement a special interface, which provides an object, you can use this object to find dependencies (other services ). Earlier containers Excalibur used this mode.
- type 2 (based on Setter): Use the setter method of Javabean to specify services for service objects. Hivemind and spring adopt this method.
- type 3 (based on constructor): the parameters of the constructor specify services for service objects. Picocontainer only uses this method. Hivemind and spring also use this method.
