IOC&DI探究

简介

业务场景: 在使用Java进行开发业务的过程中，很多时候一个业务是由各种组件组成，在每个使用到这些组件时都会毫不犹豫的new一个组件对象来使用，在小项目中这样的做法无可厚非，也不存在什么问题。但是在业务逻辑复杂并且多人协作开发的项目中，这会导致业务和组件之间的关系错综复杂而且不便于管理，对象之间的耦合度变得很高，这就是所谓的牵一发而动全身吧。 而这个问题在spring中得到了解决，它的核心在于Ioc思想。

IOC

在平时的java应用开发中，我们要实现某一个功能或者说是完成某个业务逻辑时至少需要两个或以上的对象来协作完成，在没有使用Spring的时候，每个对象在需要使用他的合作对象时，自己均要使用像new object() 这样的语法来将合作对象创建出来，这个合作对象是由自己主动创建出来的，创建合作对象的主动权在自己手上，自己需要哪个合作对象，就主动去创建，创建合作对象的主动权和创建时机是由自己把控的，而这样就会使得对象间的耦合度高了，A对象需要使用合作对象B来共同完成一件事，A要使用B，那么A就对B产生了依赖，也就是A和B之间存在一种耦合关系，并且是紧密耦合在一起，而使用了Spring之后就不一样了，创建合作对象B的工作是由Spring来做的，Spring创建好B对象，然后存储到一个容器里面，当A对象需要使用B对象时，Spring就从存放对象的那个容器里面取出A要使用的那个B对象，然后交给A对象使用，至于Spring是如何创建那个对象，以及什么时候创建好对象的，A对象不需要关心这些细节问题(你是什么时候生的，怎么生出来的我可不关心，能帮我干活就行)，A得到Spring给我们的对象之后，两个人一起协作完成要完成的工作即可。

所以控制反转IoC(Inversion of Control)是说创建对象的控制权进行转移，以前创建对象的主动权和创建时机是由自己把控的，而现在这种权力转移到第三方，比如转移交给了IoC容器，它就是一个专门用来创建对象的工厂，你要什么对象，它就给你什么对象，有了 IoC容器，依赖关系就变了，原先的依赖关系就没了，它们都依赖IoC容器了，通过IoC容器来建立它们之间的关系。

Ioc：Ioc—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。意思是对象之间的关系不再由传统的程序来控制，而是由spring容器来统一控制这些对象创建、协调、销毁，而对象只需要完成业务逻辑即可。

OC的思想最核心的地方在于，资源不由使用资源的双方管理，而由不使用资源的第三方管理，这可以带来很多好处。

• 资源集中管理，实现资源的可配置和易管理。
• 降低了使用资源双方的依赖程度，也就是我们说的耦合度。

IoC可以说是spring最核心的部分，是spring家族任意组件的基本。Ioc 本身并不能算为一种技术，而是一种思想，它使你从繁琐的对象交互中解脱出来，而专注于对象本身，更进一步突出面向对象。

// 未使用IOC之前：
public class Person {
    
    public void eat() {
        Food food = new food();
        System.out.println("I eat food:{}", food.toString());
    }
}

理解：在没有使用IOC之前，我们需要一个对象的时候需要手动进行newObject。

// 使用IOC之后：
public class Person {
    
    private Food food;
 
    public void eat() {
        System.out.println("I eat food:{}", food.toString());
    }
}

理解： 有了IOC之后，因为我们已经将对象注入了IOC容器了，所以在获取对象的时候只要通知容器我们就可以拿到我们想要的对象，而不需要每次都进行new。

IOC要解决的问题：让你脱离对依赖对象的维护，只需要随用随取，不需要关心依赖对象的任何过程。

IOC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IOC/DI思想中，应用程序就变成被动的了，被动的等待IOC容器来创建并注入它所需要的资源了。

DI

DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

• 谁依赖于谁：当然是应用程序依赖于IoC容器；
• 为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；
• 谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
• 注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

IoC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过DI（Dependency Injection，依赖注入）来实现的。

IOC容器

Spring提供了两种类型的容器，一个是BeanFactory,一个是ApplicationContext(可以认为是BeanFactory的扩展)

BeanFactory容器

如果没有特殊指定，默认采用延迟初始化策略(lazy-load)。只有当客户端对象需要访问容器中的某个受管对象的时候，才对该受管对象进行初始化以及依赖注入操作。所以相对来说，容器启动初期速度较快，所需要的资源有限。对于资源有限，并且功能要求不是很严格的场景，BeanFactory是比较合适的 IoC容器选择。

ApplicationContext容器

ApplicationContext 容器建立BeanFactory之上，拥有BeanFactory的所有功能，但在实现上会有所差别。