依赖倒置原则

依赖倒置原则

依赖倒置原则
1. 含义
2. 作用
3. 依赖的三种写法
4. 最佳实践

1. 含义

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
翻译过来，包含三层含义：

1. 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
2. 抽象不应该依赖细节；

3. 细节应该依赖抽象。
   抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化。
   在c#、java等面向对象语言中的含义：

4. 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；

5. 接口或抽象类不依赖于实现类；
6. 实现类依赖接口或抽象类。
   更加精简的定义就是“面向接口编程”——OOD（Object-Oriented Design，面向对象设计）的精髓之一。

2. 作用

减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
“变更才显真功夫”，业务需求变更永无休止，技术前进就永无止境，在发生变更时才能发觉我们的设计或程序是否是松耦合。
并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏了整个项目。在这种不使用依赖倒置原则的环境中，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续……

TDD（Test-Driven Development，测试驱动开发）开发模式就是依赖倒置原则的最高级应用。

3. 依赖的三种写法

只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！

1. 构造函数传递依赖对象

2. Setter方法传递依赖对象

3. 接口声明依赖对象

4. 最佳实践

1. 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备；

2. 变量的表面类型尽量是接口或者是抽象类；

3. 任何类都不应该从具体类派生；
4. 尽量不要覆写基类的方法；
5. 结合里氏替换原则使用；
   一个通俗的规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

在实际的项目中使用依赖倒置原则时需要审时度势，不要抓住一个原则不放，每一个原则的优点都是有限度的，并不是放之四海而皆准的真理，所以别为了遵循一个原则而放弃了一个项目的终极目标：投产上线和盈利。

来自为知笔记(Wiz)