What is IOC?

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.

Interface driven design interface driver, interface driver has many advantages, can provide different flexible subclass implementation, increase code stability and robustness, etc., but the interface must be implemented, that is, the following statement will run sooner or later: ainterface A = new ainterfaceimp (); in this way, the coupling relationship is generated, for example, Class A {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 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 ();}}} the above problems are mitigated to some extent on the table, but this code coupling has not actually 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, 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 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 the Interface): a service-able object must implement a special interface, which provides an object that can be used 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 the constructor): the parameters of the constructor can specify services for service objects. Picocontainer only uses this method. Hivemind and spring also use this method.

========================================================== ========================================================== ====

IOC is the inversion of control, and the control is reversed. In Java Development, IOC means that the classes you have designed are handed over to the system for control, rather than being controlled within your class. This is called control inversion.

Here are a few examples to illustrate what IOC is.

Suppose we want to design a girl and a boy class, where girl has a kiss method, that is, girl wants to kiss a boy. So our question is, how can girl know this boy?

In China, common methods of understanding mm and GG are as follows:
1. qingmei bamboo; 2. Parents and Friends; 3. Parents
Which one is the best?

Childhood girl knows her own boy.

Public class girl {
Void kiss (){
Boy boy = new boy ();
}
}

However, the disadvantage of creating a boy from the beginning is that it cannot be changed. And is responsible for the entire life cycle of boy. What if our girl wants to change one? (In severe cases, it is not supported for girls to change boy frequently ,#_#)

Introduction to friends and friends: the intermediary is responsible for providing boys to meet

Public class girl {
Void kiss (){
Boy boy = boyfactory. createboy ();
}
}

It is good to introduce friends and friends. If you are not satisfied, try another one. However, friends and friends boyfactory often appear in the form of singleton. Otherwise, it exists in globals and is everywhere. It is too tedious and inflexible. Why do I need such friends and friends to be involved? Why must I pay her a referral fee? What if my best friend loves my boyfriend?

Parents: give everything to parents. You don't have to worry about it. You just have to wait for Kiss.

Public class girl {
Void kiss (boy ){
// Kiss boy
Boy. Kiss ();
}
}

Well, this is the best method for girl, as long as you want to bribe her parents and give the boy to him. Then we can easily kiss with girl. It seems that the fate of traditional parents for thousands of years is really useful. At least boys and girls don't have to worry about themselves.

This is IOC, which extracts object creation and retrieval to the external. The required components are provided by external containers.

We know Hollywood principles: "Do not call us, we will call you." means you, girlie, do not call the boy. We will feed you a boy.

We should also know that the dependency inversion principle is dependence inversion princinple, dip

Eric Gamma says abstract programming is needed. Object-Oriented Programming is the core of object-oriented programming.

The component is divided into two parts: Service, the declared Implementation of the provided functions, and the implementation of the service

The advantage is that multiple implementations can be switched at will to prevent the problem of "Everything depends on everything", that is, the specifics depend on the specifics.

Therefore, our boy should implement the kissable interface. In this way, if the girl doesn't want to kiss the nasty boy, she can kiss the cute kitten and the kind grandmother.
Ii. IOC type

The type of IOC refers to several different ways for girl to get Boy. Let's explain it one by one.

IOC Type 0: No IOC
Public class girl implements servicable {
Private kissable;
Public girl (){
Kissable = new boy ();
}
Public void kissyourkissable (){
Kissable. Kiss ();
}
}

Girl builds her own boy, which is difficult to change and shared with others. She can only use it independently and is responsible for the full life cycle.

IOC Type 1, first look at the code: Code

Public class girl implements servicable {

Kissable;

Public void Service (servicemanager MGR ){
Kissable = (kissable) Mgr. Lookup ("kissable ");
}

Public void kissyourkissable (){
Kissable. Kiss ();
}

}

This situation occurs in aveon framework. When a component implements the servicable interface, it must implement the service method and pass in a servicemanager. It contains other required components. You only need to initialize the desired boy in the service method.

In addition, the object obtained from context in J2EE also belongs to type 1. It depends on the configuration file.

IOC type 2:

Public class girl {

Private kissable;

Public void setkissable (kissable ){
This. kissable = kissable;
}

Public void kissyourkissable (){
Kissable. Kiss ();
}

}

Type 2 appears in Spring framework. It uses the Set Method of Javabean to pass the required boy to girl. It must depend on the configuration file.

IOC Type 3:

Public class girl {

Private kissable;

Public girl (kissable ){
This. kissable = kissable;
}

Public void kissyourkissable (){
Kissable. Kiss ();
}

}

This is the component of picocontainer. Pass boy to girl through the constructor

Picocontainer Container = new defaultpicocontainer ();
Container. registercomponentimplementation (boy. Class );
Container. registercomponentimplementation (girl. Class );
Girl girl = (girl) container. getcomponentinstance (girl. Class );
Girl. kissyourkissable ();

References

1 http://www.picocontainer.org/presentations/JavaPolis2003.ppt
Http://www.picocontainer.org/presentations/JavaPolis2003.pdf

2 dip, Robert c Martin, Uncle Bob's excellent papers
Http://www.objectmentor.com/resources/articles/dip.pdf

3 dependency injection dependent injection, matrin Fowler extension of dip
Http://www.martinfowler.com/articles/injection.html

4 IOC framework

Picocontainer excellent IOC framework
Http://picocontainer.org/

Aveon
Http://avalon.apache.org/

Spring framework
Http://www.springframework.org/

Hivemind
Http://jakarta.apache.org/commons/hivemind