背景
这个文章主要介绍DIP、Ioc、Ioc容器和DI以及如何更好的理解这些概念，对这些概念有了理解之后我会更好的涉及组织我们的程序，更好的使用Spring Ioc容器。
依赖倒置原则(DIP):一种设计原则。
控制反转(Ioc):遵循DIP原则的一种思想或者说是设计模式。
依赖注入(DI):实现Ioc的一种手段、方法。
Ioc容器：DI框架。
依赖倒置原则(DIP)
DIP是面向对象设计(OOD)五大原则之一。注意这是一种OOD原则，并不是面向对象编程原则(OOP)。依赖倒置原则官方给出的定义是这样的：
1，高层模块不应该依赖低层模块,两者都应该依赖抽象。
2，抽象不应该依赖细节，细节应该依赖于抽象。
官方给的定义读起来挺绕口而且不好理解，其实这样的定义主要说了两个意思：
第1句话可以这样理解：高层模块依赖与低层模块，当低层模块发生改动，会影响高层模块。所有高层和底层模块都应该依赖于接口，通过接口来降低模块之间的耦合度。
第2句话可以这样理解：就是面向接口编程。不论高层模块和底层模块都应该被抽象，然后由具体的类去实现。变量、参数类型的声明都应该是抽象类型，而不应该是具体类类型。
在三层(UI、BLL、DAL)的程序架构中UI和BLL相对来说UI是高层模块，BLL是低层模块。BLL和DAL相对来说BLL是底层模块，DAL是高层模块。比如说我有一个文件操作类FileOperating，FileOperating就是高层模块，java.io包里的类就是底层模块。这里只是想说解释一下高层模块和低层模块，他们没有准确的定义，根据场景不同会有所不同。
我们来举一个具体的例子来理解DIP。假如我们造一辆汽车，按照传统习惯我们先造轮子，根据轮子的大小造底盘，根据底盘的宽窄来造车身，根据车身来造汽车。这里就出现了一个依赖关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。如果客户说轮子太小不合适，把轮子改大，就会导致车身的改动，车身改动就会引起底盘的改动，进而整个车子就会发生翻天覆地的改动。高层模块依赖于低层模块，产生了很大的耦合，低层模块发生修改就会影响高层模块，在负复杂的程序结构中依赖树会很深，问题也会被放大。
按照DIP的原则指导我们造汽车应该是：我们先造汽车，根据汽车的需要去造底盘，根据底盘的宽窄去造轮子。底层模块依赖高层模块，这样依赖关系就倒置过来了。底层模块有什么功能是根据高层模块需求来产生的，也就是高层模块定义接口(我需要什么)，然后低层模块去实现高层模块定义的接口，接口的控制器由原来底层模块定义现在变成了高层模块定义，这就是DIP的核心思想。依赖好理解，倒置是指接口的控制权从底层模块定义实现变成了高层模块定义，底层模块实现，从而导致了依赖关系的倒置，这种倒置并不是体现在代码上，而是在设计程序时需要使用DIP思想先去设计高层模块，然后根据高层模块需要设计底层模块接口，底层类实现该接口。现在我们的造车和依赖顺序变成了这样：
控制反转(Ioc)与依赖注入(DI)
控制反转(Ioc):A、B类协作完成一个功能，A调用B，而A类中并不直接创建B类的实例对象，也就说没有new B()这样的代码，这B类实例对象有外部程序来创建，B类对象实例化的操作从A类中反转到了外部。
依赖注入(DI)：A、B类协作完成一个功能。A调用B，而A类中并不直接创建B类的实例对象，这个B类实例对象由外部创建，并通过提供构造函数、set方法或属性将B类实例传递到A类内部。
Ioc容器
A调用B，B调用C，我们在编写代码时是这样的：
C c = new C();
B b = new B(c);
A a = new A(b);
如果复杂，依赖关系较深，就写大量创建对象的代码，并组织依赖关系。Ioc容器帮助我们完成这个操作。将对象的创建交给Ioc，由容器来管理对象的创建和依赖关系。
参考文章：
https://www.cnblogs.com/liuhaorain/p/3747470.html