In-depth understanding of IoC

Spring learn in the beginning, we came in contact with the IoC, as the first core concept of Spring, we need to interpret certain of its in-depth understanding of the source code before it.

IoC theory

IoC full name InversionofControl, translated as "inversion of control", which also has an alias of the DI ( DependencyInjection), i.e., dependency injection.
How to understand the "inversion of control" is good? The key to understanding it better is that we need to answer the following four questions:

Who controls
What control
Why is reversed
What reversed
Before answering these four questions, we look at the definition of the IOC:

The relationship between the so-called IOC, is the Spring IOC container is responsible for the life cycle of the object and the object

Above this sentence is the core IoC theory. How to understand this sentence? We quote an example to go forth (to read the four questions above example will not be a problem).

Have to find a girlfriend, for example (for this program ape is worthy of inquiry). Under normal circumstances we do is how to find a girlfriend? First, we need according to their needs (pretty, good body, good character) to find a sister, then ask around her hobbies, micro letters, phone number, and then send it to match up all kinds, and finally happen, no matter. as follows:

    /**

     * 年轻小伙子

     */

    public class YoungMan {

        private BeautifulGirl beautifulGirl;

        YoungMan(){

            // 可能你比较牛逼，指腹为婚

            // beautifulGirl = new BeautifulGirl();

        }

        public void setBeautifulGirl(BeautifulGirl beautifulGirl) {

            this.beautifulGirl = beautifulGirl;

        }

        public static void main(String[] args){

            YoungMan you = new YoungMan();

            BeautifulGirl beautifulGirl = new BeautifulGirl("你的各种条件");

            beautifulGirl.setxxx("各种投其所好");

            // 然后你有女票了

            you.setBeautifulGirl(beautifulGirl);

        }

    }

This is our usual way of doing things, if we need an object, usually created directly by way of this ( newBeautifulGirl()after), this process is complex and cumbersome, but we have to face every aspect, we use both complete it is also responsible for the destruction, in this case our target and it depends on the object coupled together.

In fact, we need to think about a problem? Every time we use the object really need to rely on their own to create their own it? We know that we depend on the object is not really dependent on the object itself, but rather rely on the services it provides, as long as we need it, it is able to provide timely service, as it is a gift that we take the initiative to create to us, it's not that important. Besides, compared to a lot of hard work to create it themselves but also management, rehabilitation, directly and someone gets here is not even more good?

This gives us something to send "person" is the IoC, in the above example, it is equivalent to a matchmaking company, as a matchmaking company that manages many men and women of the data, when we need a girlfriend, with direct matchmaking the company put forward our demand, the company will offer a matchmaking sister to us according to our needs, we just need to be responsible for love, have monkeys on the line. You see, this is not very straightforward.

Indeed, as a matchmaking company IoC to help us omit the cumbersome process of looking for a girlfriend, the original is now actively looking into a passive acceptance (met our requirements), more compact and lightweight. You think, ah, before and after that you would have to pommel horse, various curry favor with, everything to make their own hands, we are, ready to direct someone gets here, what a wonderful thing ah. So, simply put, IoC philosophy is to let others serve you , as shown below:

In the absence of the introduction of IoC, it is injected directly dependent on the object being dependent objects, with the IoC, and both their relationship is to unify the management and maintenance by Ioc Service Provider. What needs to be injected into the subject, a direct hit with IoC Service Provider to say hello, which will be dependent on the corresponding objects into an object that is injected in order to achieve the IOC Service Provider for the purpose of service of the object to be injected. So IoC is that simple! What turned out to be what they need to get, now we need something to let others (IOC Service Provider) gets here
now to see that the above four questions, the answer is very clear:

Who controls who : After the traditional pattern of development, we are the object of a new direct way to create an object, which means you lean on your own direct control, but with the IOC container, directly by the IoC container to control. So "Who controls who" is, of course IoC container control object.
What controls : control object.
Why is reversed : no IoC when we are dependent on the initiative to create the object in its own object, which is forward. But after With IoC, injected directly dependent objects created by the IoC container after being injected into the object, the original dependent objects get into the passive acceptance of the initiative, it is reversed.
What reversed : the acquisition is dependent on the object reversed.

With sister, but the sister how to have it? This is a science.

You might compare Niubi, when just born to a pulp for the marriage.
In most cases we will consider what kind of sister they want, they still need to greet the matchmaking company.
Another case is, you do not know what they want sister, directly with the matchmaking company said, I'm going to such a sister.

Therefore, IOC Service Provider to provide are implanted object dependent objects are also the following ways: Constructor injection, stter injection method, interface injection.

Constructor injection

Constructor injection, by definition is injected through the object in its constructor declared in the list of parameters dependent objects, so dependent objects external to know what it needs.

    YoungMan(BeautifulGirl beautifulGirl){

            this.beautifulGirl = beautifulGirl;

    }

Constructor Injection intuitive way, after the completion of object construction can be used directly, It's like you were born in your family give you specify your wife.

setter method injection

For JavaBean objects, we are generally accessed and property of the object through getter and setter methods. Providing setter methods corresponding Therefore, only the current object is the object on which it depends, it can be provided to the corresponding dependent object is injected into the subject by this method. as follows:

    public class YoungMan {

        private BeautifulGirl beautifulGirl;

        public void setBeautifulGirl(BeautifulGirl beautifulGirl) {

            this.beautifulGirl = beautifulGirl;

        }

    }

Compared to the constructor injection, setter injection will become more relaxed way more flexible, it can be injected at any time (of course, before using the dependent objects), which is like you can put what you want sister thought well, then talk to greet matchmaking company, you may want to Lin Chi styles, Zhao Liying models, even Xifeng Which of randomness strong.

Interface injection

Interface injection was relatively high-handed, because it needs to be unnecessary dependent objects implement an interface with invasive. Generally do not recommend this approach.

Various components

该图为 ClassPathXmlApplicationContext 的类继承体系结构，虽然只有一部分，但是它基本上包含了 IOC 体系中大部分的核心类和接口。

下面我们就针对这个图进行简单的拆分和补充说明。

Resource体系

Resource，对资源的抽象，它的每一个实现类都代表了一种资源的访问策略，如ClasspathResource 、 URLResource ，FileSystemResource 等。
有了资源，就应该有资源加载，Spring 利用 ResourceLoader 来进行统一资源加载。

BeanFactory 体系

BeanFactory 是一个非常纯粹的 bean 容器，它是 IOC 必备的数据结构，其中 BeanDefinition 是她的基本结构，它内部维护着一个 BeanDefinition map ，并可根据 BeanDefinition 的描述进行 bean 的创建和管理。

BeanFacoty 有三个直接子类ListableBeanFactory、 HierarchicalBeanFactory和AutowireCapableBeanFactory， DefaultListableBeanFactory为最终默认实现，它实现了所有接口。

Beandefinition 体系

BeanDefinition 用来描述 Spring 中的 Bean 对象。

BeandefinitionReader体系

BeanDefinitionReader 的作用是读取 Spring 的配置文件的内容，并将其转换成 Ioc 容器内部的数据结构：BeanDefinition。

ApplicationContext体系

这个就是大名鼎鼎的 Spring 容器，它叫做应用上下文，与我们应用息息相关，她继承 BeanFactory，所以它是 BeanFactory 的扩展升级版，如果BeanFactory 是屌丝的话，那么 ApplicationContext 则是名副其实的高富帅。由于 ApplicationContext 的结构就决定了它与 BeanFactory 的不同，其主要区别有：

继承 MessageSource，提供国际化的标准访问策略。
继承 ApplicationEventPublisher ，提供强大的事件机制。
扩展 ResourceLoader，可以用来加载多个 Resource，可以灵活访问不同的资源。
对 Web 应用的支持。

上面五个体系可以说是 Spring IoC 中最核心的部分，后面博文也是针对这五个部分进行源码分析。其实 IoC 咋一看还是挺简单的，无非就是将配置文件（暂且认为是 xml 文件）进行解析（分析 xml 谁不会啊），然后放到一个 Map 里面就差不多了，初看有道理，其实要面临的问题还是有很多的，下面就劳烦各位看客跟着 LZ 博客来一步一步揭开 Spring IoC 的神秘面纱。

参考链接

都可以看看，发人深省。

In-depth understanding of Spring IoC