Factory method mode and Ioc/di control inversion and dependency injection

Ioc--inversion of Control inversion
Di--dependency Injection Dependency Injection

To understand the above two concepts, it is necessary to clarify the following questions:

• Who are the participants?
• Dependence: Who depends on who? Why do I need to rely?
• Inject: Who injects into who? What exactly is injected?
• Control reversal: Who Controls who? Control what? Why is it called inversion (there should be a reversal in the reverse)?
• is dependency injection and control inversion the same concept?

Here is a brief answer to the above questions, to understand these problems, Ioc/di also understand.
(1) Who are the participants:

There are generally three-party participants, one is an object, one is a Ioc/di container, and the other is an external resource for an object.
And the noun to explain, an object refers to an arbitrary, ordinary Java object; The Ioc/di container is simply a framework program used to implement the Ioc/di function, and the object's external resources refer to what the object needs, but it is obtained from outside the object, collectively referred to as resources, such as: other objects required by the object, or the file resources required by the object, etc.

(2) who depends on who:

Of course, a container that relies on Ioc/di for an object.

(3) Why you need to rely on:

Objects require IOC/DI containers to provide the external resources required by the object

(4) who is injected into whom:

It's obvious that Ioc/di's container injects an object.

(5) Exactly what to inject:

is the external resources needed to inject an object

(6) Who controls who:

Of course, it's Ioc/di's container to control the object.

(7) Control what:

The main control is the creation of object instances

(8) Why reverse is called:

Reversal is relative to the positive, then what is positive? Consider the general application, what would you do if you were to use C in a? Of course, it is directly to create a C object, that is, in class A to take the initiative to obtain the required external resource C, this situation is called forward. So what's the reverse? Is that class A no longer takes the initiative to acquire C, but passively waits, waits for the Ioc/di container to get an instance of C, and then injects the reverse into Class A.

Using the legend to illustrate, first look at the time when there is no Ioc/di, the general Class A using Class C, 7 is shown:

Figure 7 General A uses C

When a Ioc/di container is available, Class A no longer takes the initiative to create C, as shown in 8:

Figure 8 Class A is no longer actively creating C

Instead of passively waiting, wait for the Ioc/di container to get an instance of C, and then inject the reverse into Class A, as shown in 9:


Figure 9 Ioc/di Container Post-Program structure

(9) is dependency injection and control inversion the same concept?

According to the above, it should be seen that dependency injection and inversion of control are different descriptions of the same thing, and in one way or another, they describe different angles. Dependency Injection is described from an application perspective, where dependency injection can be described as the complete point: The application relies on the container to create and inject the external resources it needs, while control inversion is described from the container's perspective, describing the complete point: the container control application, The external resources required by the container to inject the application into the application in reverse.

(10) Summary:

In fact, the biggest change Ioc/di to the programming is not from the code, but from the thought, has occurred "master-slave Transposition" change. The application was originally the boss, to get what resources are active attack, but in Ioc/di thought, the application becomes passive, passively wait for the Ioc/di container to create and inject the resources it needs.
Such a small change is actually a big step forward in programming thinking, which effectively separates the object and the external resources it needs, makes them loosely coupled, facilitates functional reuse, and, more importantly, makes the entire architecture of the program very flexible.

2: What is the relationship between factory method mode and Ioc/di?

From a certain point of view, their ideas are very similar.
The above said, with the Ioc/di after the application is no longer active, but passively waiting for the container to inject resources, so when writing code, once the use of external resources, will open a window, so that the container can inject, that is, to provide the container to use the injection of the way, of course, this is not our focus, Let's not talk about it, using a setter to inject an example, to see what the code looks like with Ioc/di, the sample code is as follows:

public class A { /** * Waiting to be injected in */ Private c c = null; /** * Method of injecting resource C * @param c is injected with resources */ public void SetC (c c) { THIS.C = C; } public void T1 () { You need to use C here, but do not let the initiative to create C, how to do? Anyway, the need to inject from the outside, so more worry, You don't have to take care of how to get C, just use it. c.tc (); } }

The sample code for interface C is as follows:

Public interface C { public void TC (); }

As you can see from the example code above, when you write code in a, when you encounter a need for external resources, you provide an injection path that requires an external injection and uses these objects.
Then look at the factory method mode, how to achieve the same function above, in order to differentiate, respectively named A1 and C1. This time in the A1 to use the C1 object, is not A1 to take the initiative to get the C1 object, but to create a factory method, similar to an injection path; then subclasses, suppose called A2 Bar, from A2 to get C1 object, in the call, replace the A1 of the corresponding method, Equivalent to the reverse injection back into A1, the sample code is as follows:

Public abstract class A1 { /** * Factory method, create C1, similar to the way to inject from sub-class * @return Object instance of C1 */ Protected abstract C1 createC1 (); public void T1 () { // Here you need to use C1 class, but I don't know which one to use // you don't have to create C1 , what to do?        // It 's going to happen in a subclass anyway, and there's no way to get it. C1 , just use it right now. CreateC1 (). TC (); } }

The sample code for the subclass is as follows:

public class A2 extends A1 { Protected C1 createC1 () { Real choice of concrete implementation and creation of objects return new C2 (); } }

The C1 interface is the same as the previous C interface, and the C2 implementation class is empty, just a demo, so it's not going to show their code.
Carefully understand the above example, compare their implementation, especially from the ideological level, will find that the factory method mode and Ioc/di ideas are similar, are " Active passive ", the " master-slave transposition ", thus obtaining a more flexible program structure.

Reproduced:

http://baitai.iteye.com/blog/792980

http://www.iteye.com/topic/692793

Factory method mode and Ioc/di control inversion and dependency injection