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

设计模式 前端之家
前端之家收集整理的这篇文章主要介绍了设计模式学习之——六大设计原则之三：依赖倒置原则，前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。
定义：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:
司机驾驶奔驰车：

司机类：
@H_502_103@ [java] view plain copy
  1. publicclassDriver
  2. {
  3. publicvoiddriver(Benzbenz)
  4. {
  5. benz.run();
  6. }
  7. }
奔驰类：
@H_502_103@ [java] view plain copy
  1. publicclassBenz
  2. {
  3. publicvoidrun()
  4. {
  5. System.out.printIn("奔驰运行");
  6. }
  7. }
场景类：
@H_502_103@ [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 张三要开宝马怎么办？？？
首先 我们需要产生一个宝马类（代码略：类似奔驰类）
但是！张三却无法开，因为没有对应的方法
我们的设计出现了问题：司机类与奔驰类是紧耦合关系，导致可维护性降低，可读性降低（阅读两个文件），稳定性降低（增加车就需要修改司机类）
还导致并行开发的风险（一段程序异常波及一个功能，一个模块，甚至整个项目）
导致并行开发风险的原因：如果甲负责开发汽车类，乙负责开发司机类。此时甲未完成，则乙也无法完全编码，因为缺少汽车类，无法编译通过。

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

解决：引入依赖倒置原则

司机接口：
@H_502_103@ [java] view plain copy
  1. publicinterfaceIDriver
  2. {
  3. publicvoiddriver(ICarcar);
  4. }
司机实现类：
@H_502_103@ [java] view plain copy
  1. publicclassDriverimplementsIDriver
  2. {
  3. publicvoiddriver(ICarcar)
  4. {
  5. car.run();
  6. }
  7. }
汽车接口：
@H_502_103@ [java] view plain copy
  1. publicinterfaceICar
  2. {
  3. publicvoidrun();
  4. }
汽车实现：
@H_502_103@ [java] view plain copy
  1. publicclassBenzimplementsICar
  2. {
  3. publicvoidrun()
  4. {//输出奔驰运行
  5. }
  6. }
  7. publicclassBMWimplementsICar
  8. {
  9. publicvoidrun()
  10. {//输出宝马运行
  11. }
  12. }
在业务场景中： ”抽象不应依赖细节“
@H_502_103@ [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类型进行操作，屏蔽了细节对抽象的影响。
若要开宝马，则：
@H_502_103@ [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. 构造函数传递依赖关系
@H_502_103@ [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方法传递依赖对象
@H_502_103@ [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

猜你在找的设计模式相关文章

适配器模式-让不兼容的接口得以适配
适配器模式将一个类的接口转换成客户期望的另一个接口，使得原本接口不兼容的类可以相互合...
策略模式-定义一个算法族
策略模式定义了一系列算法族，并封装在类中，它们之间可以互相替换，此模式让算法的变化独...
设计模式之高质量代码
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码，它是针对软件开发中经常遇到的...
模板方法模式-封装一套算法流程
模板方法模式在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中，使得子类可以在...
迭代器模式-统一集合的遍历方式
迭代器模式提供了一种方法，用于遍历集合对象中的元素，而又不暴露其内部的细节。
单例模式的五种实现方式及优缺点
单例模式（Singleton Design Pattern）保证一个类只能有一个实例，并提供一个全局访问点。
组合模式-统一的处理个别对象与组合对象
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构，使得客户可以用一致的方...
装饰者模式-动态的包装原有对象的行为
装饰者模式能够更灵活的，动态的给对象添加其它功能，而不需要修改任何现有的底层代码。
观察者模式-将消息通知给观察者
观察者模式（Observer Design Pattern）定义了对象之间的一对多依赖，当对象状态改变的时候...
代理模式-访问对象的代理而非其本身
代理模式为对象提供一个代理，来控制对该对象的访问。代理模式在不改变原始类代码的情况下...
算法设计模式多媒体技术正则表达式ElasticsearchFlinkHadoopIDE
受约束摘*day25Java常用类库置信lamda留存持续录入年后正则表达式303.17regularexpre匹多模适20130322基础理论pathmunge涵义reectok需要转义的特资源分享validationex简明魔法里弄形如源码实现完备actionscript