依赖倒置原则与springIOC学习精要.ppt

设计模式之  ——依赖倒转原则 初识 依赖倒转、控制反转、依赖注入三者含义和目标基本一致，即通过抽象接口解耦和消除依赖关系 依赖倒置的核心思想是依赖于抽象。 1、高层模块不应该依赖低层模块，两者都应该依赖其抽象； 2、抽象不应该依赖细节； 3、细节应该依赖抽象。 ? 高层模块和低层模块：每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。 细节和抽象：在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。 依赖倒置原则在Java语言中的表现就是： 1、模块间的依赖是通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的； 2、接口或抽象类不依赖于实现类； 3、实现类依赖接口或抽象类。 一句话：面向接口编程 反例： 代码： 司机通过调用奔驰车的run方法开动奔驰车 public class Driver { //司机的主要职责就是驾驶汽车 public void drive(Benz benz){ benz.run(); } } public class Benz { //汽车肯定会跑 public void run(){ System.out.println(奔驰汽车开始运行...); } } 有车，有司机，在Client场景类产生相应的对象 public class Client { public static void main(String[] args) { Driver zhangSan = new Driver(); Benz benz = new Benz(); //张三开奔驰车 zhangSan.drive(benz); } } ? 通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题。但是业务需求变更永无休止，在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？我们先把宝马车产生出来 public class BMW { //宝马车当然也可以开动了 public void run(){ System.out.println(宝马汽车开始运行...); } } 宝马车也产生了，但是我们却没有办法让张三开动起来，为什么？因为张三没有开动宝马车的方法。一个司机竟然只能开奔驰车而不能开宝马车，这也太不合理了！在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象，我们的设计出现了问题：司机类和奔驰车类之间是一个紧耦合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本。从这里，我们知道使用抽象才能解决这个问题。 稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到“我自岿然不动”。 ???”减少并行开发引起的风险”，什么是并行开发的风险？并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏了整个项目。一个团队，20人开发，各人负责不同的功能模块，甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过！在缺少Benz类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续…，这在90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作，但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队的协作结果，一个“英雄”再牛也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，那然后呢？依赖倒置原则就隆重出场了！ 正例： public interface IDriver { //是司机就应该会驾驶汽车 public void drive(ICar car); } public class Driver implements IDriver{