设计原则之依赖倒转原则

之前已经总结过单一职责原则、开闭原则、里氏替换原则和接口隔离原则，这四个原则和这篇的依赖倒转原则合称SOLID原则。

依赖倒转原则 Dependency Inversion Principle，DIP

依赖倒转原则定义
High-level modules shouldn’t depend on low-level modules.Both modules should depend on abstractions.In addition, abstractions shouldn’t depend on details.Details depend on abstractions.
高层模块不要依赖低层模块，高层模块合低层模块应该通过抽象来互相依赖。
抽象不要依赖具体实现细节，具体实现细节应该依赖抽象。

这里高层模块和低层模块的划分，在调用链上，调用者属于高层，被调用者属于低层。在业务代码的开发中，高层依赖低层模块，调用低层模块没有任务问题，但是依据依赖倒转原则，低层模块应该依赖抽象，高层模块不应该直接调用依赖具体的低层模块，应该通过调用低层模块的抽象来实现依赖。可以减少类间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，降低修改程序造成的风险。

从依赖倒转字面上看，和控制反转、依赖注入有些相似，那它们之间有什么区别和联系呢？从依赖倒转原则定义上看，和“基于接口而非实现编程”又非常相似，那它们之间又有什么区别呢？

控制反转
控制反转，Inversion Of Control，IOC。
控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。所以说这里的“控制“指的是对程序执行流程对控制，而”反转“指对是在没有使用框架之前，程序员自己控制整个程序对流程执行，使用框架后，整个程序对执行流程通过框架来控制。流程的控制权从程序员”反转“给来框架。

依赖注入
依赖注入，Dependency Injection，DI。
依赖注入不同于控制反转，依赖注入是一种具体的编程实现技巧。用一句话概括就是：不通过new的方式在类内部创建被依赖类的实例对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用。通过依赖注入的编码方式实现依赖类对象的传递，提高累代码的可扩展性，当函数参数通过抽象类接收被依赖的类对象，我们可以灵活地替换具体的依赖的类实例对象进行传递。

Java Spring框架的两大特性，控制反转和依赖注入，其实说的是一个事情，控制反转主要是通过依赖注入实现的。在实际开发中，项目的类可能会涉及几十上百甚至几百个类，如果其互相依赖注入的关系，都要程序员手动创建类对象，并注入到指定的类，这部分工作是比较繁琐的，且跟具体业务实现是无关的，Spring就通过提供扩展点，让用户配置类之间的依赖关系，将类的创建和注入以及生命周期交给框架管理。类的创建和管理控制通过依赖注入的编程技巧反转给了框架。

基于接口而非实现编程
基于接口而非实现编程，分离了抽象和实现，高层系统依赖抽象编程，不依赖具体的实现，当实现需求发生变更时，只需要修改或者新增具体的实现，而不需要修改高层系统的逻辑代码。越抽象、越顶层、越脱离具体某一实现的设计，越能提高代码的灵活性，越能应对未来的需求变化。

依赖倒转原则是一种编程技巧，主要强调抽象，基于接口而非实现编程是一种编程思想原则，强调上下游系统调用的稳定性，主要强调接口。但都是基于开闭原则的设计原则，提高代码的可扩展性。