---- 概念 ----

◆1.依赖倒置原则（DIP，Dependency Inverse Principle）
强调系统的高层组件不应当依赖于底层组件；并且不论是高层组件还是底层组件都应当依赖于抽象。

◆2.依赖（Dependency）
组件A如果：①.持有B的引用，②调用B的方法，③创建（new）B，则A对B产生依赖

◆3.控制（Control）
A依赖B，则B拥有“控制权”，因为B的某种变化可能会引起A的变化

◆4.控制反转（IoC，Inverse of Control）
就是将控制方“往高处/上层”转移
控制反转是实现依赖倒置的一种方法

◆5.依赖注入（DI，Dependency Injection）
组件通过构造函数或者setter方法，将其依赖暴露给上层；上层要设法取得组件的依赖，并将其传递给组件。
依赖注入是实现控制反转的一种手段

---- DIP，DI与IoC 不得不说的故事 ----

“高层组件不应当依赖于低层组件；并且不论是高层组件还是低层组件都应当依赖于抽象！”
—— DIP

于是，按照DIP说的，我们把底层组件抽象为接口与实现类，高层组件依赖此接口。看起来，大家都是依赖抽象了，不过，我们应该在何处、如何取得具体的底层组件实例？？

1.通过底层组件工厂（纯虚构），将"new"操作"集中起来管理"。于是高层组件对底层组件的依赖转变为了对"纯虚构"出来的工厂的依赖（这就是IoC的一种实现手段）。新的问题来了，其实工厂也是不小的麻烦。
（地点：高层组件内部；方式：通过底层组件工厂）

2.高层组件咆哮到：“底层组件和工厂都TM伤不起！动不动就变！！有木有！！我不管了啊！要调用我的组件们，我给你们开放注入具体实现的接口（构造函数注入，setter/getter注入），你们自己看着办啊 ！！！”——于是，依赖注入（DI）的基础建立了起来，同时，对依赖关系的管理任务也交给了上层（这就是IoC的一种实现手段）。
（地点：高层组件的使用者内部；方式：设法取得具体实现，并传递给高层组件）

2.5 高层组件的高层组件无语了，但是它很淡定地如法炮制，将这个“麻烦”交给了它的高层组件，and so on...最终，最高处的那个组件（一般它叫“应用”），表示鸭梨非常大：“你们把所有的依赖都转给我了？！？！这不是坑爹吗？”

3.此时，"工厂"的角色和范畴扩大，它接纳了“管理整个应用的所有实现类对象”的任务。它通过某种方式（比如Spring的XML配置方式、注解方式；Guice的编程方式）向应用提供了管理组件之间依赖关系的接口，于是，应用所要考虑的所有依赖关系都可以委托给这样的"工厂"了，"工厂"成为了应用唯一依赖 —— 整个应用的“控制权”全都由具体实现（包括底层组件具体实现、甚至底层组件工厂等）反转至了"工厂"的依赖接口中，“IoC容器”是它响亮的新名字！
（地点：IoC容器；方式：通过IoC容器的API） 4.IoC容器的引入，让整个应用变得十分灵活，组件之间可以“热插拔”。这也正是DIP的初衷。 * 通过IoC容器，我们在使用一个组件时，需要指定它的依赖，以及它的依赖的依赖...and so on，这形成了一个“对象图”的概念