设计模式学习之——六大设计原则之三：依赖倒置原则

定义：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.

定义的含义：

a. 高层模块不应依赖低层模块，两者应都依赖其抽象

b. 抽象不应依赖细节

c. 细节应依赖抽象

（细节即实现类，抽象即接口或抽象类）

在Java中的表现：

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

b. 接口或抽象类不依赖于实现类

c. 实现类依赖接口或抽象类

用更加精简的定义就是： 面向接口编程——OOD(Object-Oriented-Design,面向对象设计)的精髓之一。

下面，我们通过反证法来证明：

论题：依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高嗲吗的可读性和可维护性。

反论题：不使用依赖倒置原则也可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

eg:

司机驾驶奔驰车：

司机类：

[java] view plain copy

1. publicclassDriver
2. {
3. publicvoiddriver(Benzbenz)
4. {
5. benz.run();
6. }
7. }

奔驰类：

[java] view plain copy

1. publicclassBenz
2. {
3. publicvoidrun()
4. {
5. System.out.printIn("奔驰运行");
6. }
7. }

场景类：

[java] view plain copy

1. publicclassClient
2. {
3. publicstaticvoidmain(String[]args)
4. {
5. DriverzhangSan=newDriver();
6. Benzbenz=newBenz();
7. zhangSan.driver(benz);
8. }
9. }

Now 张三要开宝马怎么办？？？

首先 我们需要产生一个宝马类（代码略：类似奔驰类）

但是！张三却无法开，因为没有对应的方法

我们的设计出现了问题：司机类与奔驰类是紧耦合关系，导致可维护性降低，可读性降低（阅读两个文件），稳定性降低（增加车就需要修改司机类）

还导致并行开发的风险（一段程序异常波及一个功能，一个模块，甚至整个项目）

导致并行开发风险的原因：如果甲负责开发汽车类，乙负责开发司机类。此时甲未完成，则乙也无法完全编码，因为缺少汽车类，无法编译通过。

由以上证明，反论题不成立！！！

解决：引入依赖倒置原则

司机接口：

[java] view plain copy

1. publicinterfaceIDriver
2. {
3. publicvoiddriver(ICarcar);
4. }

司机实现类：

[java] view plain copy

1. publicclassDriverimplementsIDriver
2. {
3. publicvoiddriver(ICarcar)
4. {
5. car.run();
6. }
7. }

汽车接口：

[java] view plain copy

1. publicinterfaceICar
2. {
3. publicvoidrun();
4. }

汽车实现：

[java] view plain copy

1. publicclassBenzimplementsICar
2. {
3. publicvoidrun()
4. {//输出奔驰运行
5. }
6. }
7. publicclassBMWimplementsICar
8. {
9. publicvoidrun()
10. {//输出宝马运行
11. }
12. }

在业务场景中： ”抽象不应依赖细节“

[java] view plain copy

1. publicclassClient
2. {
3. publicstaticvoidmain(String[]args)
4. {
5. IDriverzhangSan=newDriver();
6. ICarbenz=newBenz();
7. zhangSan.driver(benz);
8. }
9. }

Client是高层业务逻辑，对低层模块的依赖建立在抽象上。 zhangSan都是以IDrvier类型进行操作，屏蔽了细节对抽象的影响。

若要开宝马，则：

[java] view plain copy

1. publicclassClient
2. {
3. publicstaticvoidmain(String[]args)
4. {
5. IDriverzhangSan=newDriver();
6. ICarbmw=newBMW();
7. zhangSan.driver(bmw);
8. }
9. }

在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块不需修改。

注：定义变量，必然要有类型：有表面类型和实际类型

表面类型：定义的时候赋予的

实际类型：对象的类型

如：zhangSan的表面类型是IDrvier，实际类型是Driver

依赖倒置原则对并行开发的影响：

两个类有依赖关系，只要制定两者接口，就可以独立开发，单元测试也可以独立运行，而TDD（Test-Driven Development,测试驱动开发）开发模式就是依赖倒置原则的最高应用。

依赖的三种写法：

1. 构造函数传递依赖关系

[java] view plain copy

1. publicinterfaceIDriver
2. {
3. publicvoiddriver(ICarcar);
4. }
5. publicclassDriverimplementsIDriver
6. {
7. privateICarcar;
8. publicDriver(ICar_Car)
9. {
10. this.car=_Car;
11. }
12. publicvoiddriver(ICarcar)
13. {
14. this.car.run();
15. }
16. }

2. Setter方法传递依赖对象

[java] view plain copy

1. publicinterfaceIDriver
2. {
3. publicvoidsetCar(ICarcar);
4. publicvoiddriver();
5. }
6. publicclassDriverimplementsIDriver
7. {
8. privateICarcar;
9. publicvoidsetCar(ICar_Car)
10. {
11. this.car=_Car;
12. }
13. publicvoiddriver(ICarcar)
14. {
15. this.car.run();
16. }
17. }

3. 接口声明依赖对象：接口注入

（即Client类中的实现方法）

使用：

a. 每个类尽量都有接口或抽象类

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

c. 任何类都不应从具体类派生

d. 尽量不要重写基类的方法

e. 结合里氏替换原则使用

何为倒置：

对现实世界的事务进行抽象，抽象的结果就是有了抽象类和接口，根据系统设计的需要产生抽象间的依赖，代替了人们传统思维中的事物间的依赖。

依赖倒置原则的逆向：

eg: 法律：杀人偿命.

如果用依赖倒置原则来考虑：杀人是抽象的含义，怎么杀，杀什么人，为何杀人都未定义，只要杀人了就要偿命。

那么：如果我们杀了一个十恶不赦的坏人呢？或者说警察在执行任务的时候击毙了歹徒呢？

这个时候，杀人偿命就不能在这里使用了。

所以所：我们要结合实际出发，不能抓住一个原则不放，每个原则的优点是有限的。不能为了遵循一个原则而放弃了一个项目的终极目标：投产上线和盈利。

欢迎转载，转载注明出处，谢谢

Mr.傅：阅读自《设计模式之禅》

来源：http://blog.csdn.net/fu222cs98/article/details/21351051