控制反转和依赖注入

控制反转和依赖注入是设计思想，目的就是松耦合，是同一个概念的不同角度描述。

什么角度？       

应用程序 和 容器。

依赖注入 ——应用程序角度 ：应用程序依赖容器创建并注入它所需要的外部资源；    

控制反转——容器角度 ： 容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。

外部资源 ：不是你本身的，那就是外部的。

依赖：不是我自身的，却是我需要的，都是我所依赖的。一切需要外部提供的，都是需要进行依赖注入的。

每个对象都需要获取与其合作的对象（也就是它所依赖的对象）的引用。如果这个获取过程要靠自身实现，那么将导致代码高度耦合并且难以维护和调试。

例子

你饿了，需要吃饭，然后做饭。          ——主动创建

你饿了，需要吃饭，点了外卖，配送员去拿到外卖，给你送来。    ——IoC/DI

你是应用程序，配送员是IoC容器，外卖就是外部资源。

你饿了，需要吃饭，去餐厅吃饭，吃完盘子不用洗。

你是应用程序，餐厅是IoC容器，饭就是外部资源，吃完不用洗盘子，垃圾不用你回收，饭的生命周期不用你管。

A类需要B，B就是A的外部资源。

在A类中主动去获取所需要的外部资源B，这种情况被称为正向的      —— new  B()；

有IoC/DI的容器后，A类不再主动去创建B了，而是被动等待：          ——  @Autowired  private   B    b;

1.IoC/DI的容器获取一个B的实例，

2.然后反向的注入到A类中

应用程序从主动变为被动的等待IoC/DI容器来创建并注入它所需要的资源了。

Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。

谁控制谁？当然是IoC 容器控制了对象；

控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。

为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；

哪些方面反转了？依赖对象的获取被反转了。

应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。

由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

依赖注入：

动态的向某个对象提供它所需要的其他对象。

谁依赖于谁：当然是应用程序依赖于IoC容器；

为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；

谁注入谁：明显IoC容器注入应用程序某个对象，应用程序依赖的对象；

注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。

控制反转：

创建对象的控制权进行转移，以前创建对象的主动权和创建时机是由自己把控的，而现在这种权力转移到第三方，

控制的什么被反转了？就是：获得依赖对象的方式反转了。

Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转。

 A对象需要使用合作对象B来共同完成一件事，A要使用B，那么A就对B产生了依赖，也就是A和B之间存在一种耦合关系，并且是紧密耦合在一起，而使用了Spring之后就不一样了，创建合作对象B的工作是由Spring来做的，Spring创建好B对象，然后存储到一个容器里面，当A对象需要使用B对象时，Spring就从存放对象的那个容器里面取出A要使用的那个B对象，然后交给A对象使用，至于Spring是如何创建那个对象，以及什么时候创建好对象的，A对象不需要关心这些细节问题(你是什么时候生的，怎么生出来的我可不关心，能帮我干活就行)，A得到Spring给我们的对象之后，两个人一起协作完成要完成的工作即可。