依赖倒置原则.pptVIP

TMS 作品 软件体系结构 培析 第一章 依赖倒置原则 一 基本定义 依赖倒置原则(Dependence Inversion Principle, DIP)这个名字看着有点别扭，“依赖，这到底是什么意思?依赖倒置原则的原始定义是: 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 翻译过来，包含三层含义: 高层模块不应该依赖低层模块，两者都应该依赖其抽象; 抽象不应该依赖细节 细节应该依赖抽象. 依赖倒置原则在Java语言中的表现就是： 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。 接口或抽象类不依赖于实现类， 实现类依赖接口或抽象类。 更加精简的定义就是“面向接口编程.SOD (Object-OuientedDesign，面向对象设计)的精髓之一 二 契约式编程 现在的汽车越来越便宜了，一个卫生间的造价就可以买到一辆不错的汽车，有汽车就必然有人来驾驶，司机驾驶奔驰车的类图如图3一1所示。 public class Driver { //司机的主要职责就是驾驶汽车 public void drive(Benz benz){ benz.run(); } } 我们在一段貌似磐石的程序上加上一块小石头:张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢?麻烦出来了，那好，我们走一步是一步，我们先把宝马车产生出来，实现过程如代码清单3-4所示。 public class BMW { //宝马车当然也可以开动了 public void run(){ System.out.println(宝马汽车开始运行...); } } 宝马车也产生了，但是我们却没有办法让张三开动起来，为什么?张三没有开动宝马车的方法呀!一个拿有C驾照的司机竟然只能开奔驰车而不能开宝马车，这也太不合理了!在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象，我们的设计出现了问题:司机类和奔驰车类之间是紧藕合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低 建立两个接口:IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法，其实现过程如代码清单3-5所示 public interface IDriver { //是司机就应该会驾驶汽车 public void drive(ICar car); } public class Driver implements IDriver{ //司机的主要职责就是驾驶汽车 public void drive(ICar car){ car.run(); } } public interface ICar { //是汽车就应该能跑 public void run(); } public class BMW implements ICar{ //宝马车当然也可以开动了 public void run(){ System.out.println(宝马汽车开始运行...); } } public class Benz implements ICar{ //汽车肯定会跑 public void run(){ System.out.println(奔驰汽车开始运行...); } } public class Client { public static void main(String[] args) { IDriver zhangSan = new Driver(); //ICar benz = new Benz(); ICar bmw = new BMW(); //张三开奔驰车 zhangSan.drive(bmw); } } Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的表面类型是IDriver, Benz的表面类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释?确实如此，zhangSan的表面类型是IDriver,是一个接口，是抽象的、非实体化的，在其后的所有操作中，zhangSan都是以工Driver类型进行操作，屏蔽了细节对抽象