Spring IoC 原理及实现

依赖倒置原则

说到 IoC（Inversion of Control，反转控制），得先简单说下什么是 Dependency Inversion Principle（依赖倒置原则），DI 是实现 IoC 的一种方式。

假设我们设计一辆汽车有两种方案：

1. 方案一：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个「依赖」关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。
   
2. 方案二：我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。
   

在方案一中，如果说要修改轮胎设计，则会导致轮胎设计之后的流程也重新走一遍；而在方案二中，如果需要修改轮胎设计，只需要修改轮胎就行，而不需要修改其他内容。

这就是依赖倒置原则——把原本的高层建筑依赖底层建筑「倒置」过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的「牵一发动全身」的情况。

两者的关系：

以上内容来自：Spring IoC有哪些好处？

IoC

IoC（Inversion of Control，反转控制）：在应用程序中的组件需要获取资源时，传统的方式是组件主动从容器中获取所需要的资源。而在 IoC 的思想中反转了资源的获取方向：改由容器主动将资源推送给需要的组件，开发人员不需要知道容器是如何创建资源对象的，只需要提供接收资源的方式即可。

用找对象举个例子：
你如果是主动找的话，你看到了一个中意的，需要你自己去问人要联系方式；而如果你在婚姻介绍所（容器）呢，说了你的标准后，有关人员就会将符合你意愿的另一个人的联系方式给你。

IoC 实现

在通过 IoC 容器读取 Bean 的实例之前，我们需要将 IoC 容器本身实例化，在 Spring 中提供了两种 IoC 的实现方式：

1. BeanFactory：IoC 容器的基本实现，是面向 Spring 容器本身的，开发人员一般不用；
2. ApplicationContext：BeanFactory 的子接口，提供了更多的特性，面向开发人员使用。
   

ApplicationContext 的主要实现类：

1. ClassPathXmlApplicationContext：基于对应类路径下的XML格式的配置文件的实现类
2. FileSystemXmlApplicationContext：基于对应文件系统中的XML格式的配置文件的实现类
3. AnnotationConfigApplicationContext：基于注解配置的实现类

BeanFactory 和 ApplicationContext 的区别：

1. BeanFactory 才是 Spring 容器中的顶层接口，ApplicationContext 是它的子接口。
2. 创建对象的时间点不一样：
   ApplicationContext：只要一读取配置文件，默认情况下就会创建对象。
   BeanFactory：什么使用什么时候创建对象

ConfigurableApplicationContext：是 ApplicationContext 的子接口，包含一些扩展方法，如 refresh() 和 close()，这两个方法让 ApplicationContext 有了启动、关闭以及刷新的能力。

本质是用到了 DI（Dependency Injection，依赖注入），DI 的相关博客，敬请期待~

思考

IoC 是一种思想，而我们有时候听到的「将 Bean 交给 Spring 的 IoC 容器管理 」这句话容易给人以「IoC 是 Spring 的容器」的假象。