设计模式原则—依赖倒置原则（DIP）

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在面向对象中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

依赖倒置原则的核心思想是面向接口编程。

在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖抽象类或接口，而不是依赖具体类。具体的类只负责具体的业务逻辑，修改具体的类不影响与特定业务有关的依赖。在结构化设计中，可以看到底层的模块对高层抽象模块的实现，这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时会严重影响到高层抽象的模块。面向对象方法的依赖关系恰好相反，具体实现类依赖于抽象类和接口。为此，在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，通过具体的实现类来实现该业务，业务内容的修改不影响运行时业务方法的调用。