设计模式之 依赖倒置原则

依赖倒置原则，翻译过来，包含三层含义：

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

每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块；

原子逻辑的再组装就是高层模块；

抽象就是指接口或抽象类，两者都是不能直接被实例化的；

细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象；

一.  不使用依赖倒置原则

  奔驰车可以提供一个方法run，代表车辆运行，实现过程如代码清代3-1所示。

public class Driver {

 

//司机的主要职责就是驾驶汽车

 

public void drive(Benz benz){

benz.run();

} }

司机通过调用奔驰车的run方法开动奔驰车，其源代码如代码清单3-2所示。

public class Benz {



//汽车肯定会跑



public void run(){

System.out.println( "奔驰汽车开始运行..." );

} }

有车，有司机，在Client场景类产生相应的对象，其源代码如代码清代3-3所示

public class Client {

 

public static void main(String[] args) {

Driver zhangSan = new Driver();

Benz benz = new Benz();

 

//张三开奔驰车

zhangSan.drive(benz);

 

     接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成，Driver实现类如代码清单3-6所示。} }

    通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题。我们常说“危难时刻见真情”，我们把这句话移植到技术上就成了“变更才显真功夫”，业务需求变更永无休止，技术前进就永无止境，在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？麻烦出来了，那好，我们走一步是一步，我们先把宝马车产生出来，实现过程如代码清单3-4所示。



public class BMW {

 

//宝马车当然也可以开动了

 

public void run(){

System.out.println( "宝马汽车开始运行..." );

 

}  }

     宝马车也产生了，但是我们却没有办法让张三开动起来，为什么？张三没有开动宝马车的方法呀！一个拿有C照的司机竟然只能开奔驰车而不能开宝马车，这也太不合理了！在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象，我们的设计出现了问题：司机类和奔驰车类之间是一个紧耦合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本，这样的依赖关系谁肯承担！



     注意 设计是否具备稳定性，只要适当的“松松土”，观察“设计的蓝图”是否还可以茁壮的成长就可以得出结论，稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到“我自岿然不动”。

     我们继续证明，“减少并行开发引起的风险”，什么是并行开发的风险？并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏了整个项目，为什么并行开发就有这个风险呢？一个团队，20人开发，各人负责不同的功能模块，甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过！在缺少Benz类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续…，这在90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作，但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队的协作结果，一个“英雄”再牛X也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，那然后呢？依赖倒置原则就隆重出场了！

     根据以上证明，如果不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，增加并行开发引起的风险，降低代码的可读性和维护性。承接上面的例子，引入依赖倒置原则后的类图如图3-2所示。

二.  使用依赖倒置原则


建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法，其实现过程如代码清单3-5所示。

public interface IDriver {

 

//是司机就应该会驾驶汽车

 

public void drive(ICar car);

 

}

接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成，Driver实现类如代码清单3-6所示。

public class Driver implements IDriver{

 

//司机的主要职责就是驾驶汽车

 

public void drive(ICar car){

car.run();

}  }

在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car需要在高层模块中声明。

 ICar及其两个实现类的实现过程如代码清单3-7所示。

public interface ICar {

 

//是汽车就应该能跑

public void run();

}

 

public class Benz implements ICar{

 

//汽车肯定会跑

public void run(){

System.out.println( "奔驰汽车开始运行..." );

} }

 

public class BMW implements ICar{

 

//宝马车当然也可以开动了

 

public void run(){

System.out.println( "宝马汽车开始运行..." );

} }

在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此我们在高层次的模块中应用都是抽象，Client的实现过程如代码清单3-8所示。

代码清单3-8 业务场景

public class Client {

public static void main(String[] args) {

IDriver zhangSan = new Driver();

ICar benz = new Benz();

//张三开奔驰车

zhangSan.drive(benz);

} }

     Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的显示类型是IDriver，benz的显示类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释？确实如此，zhangSan的显示类型是IDriver，是一个接口，是抽象的，非实体化的，在其后的所有操作中，zhangSan都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，张三如果要开宝马车，也很容易，我们只要修改业务场景类就可以，实现过程如代码清单3-9所示。

代码清单3-9 张三驾驶宝马车的实现过程

public class Client {

 

public static void main(String[] args) {

 

IDriver zhangSan = new Driver();

 

ICar bmw = new BMW();

 

//张三开奔驰车

 

zhangSan.drive(bmw);

 

} }

在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要做任何修改，业务就可以运行，把“变更”引起的风险扩散降低到最小