1. 定义
依赖倒置原则 (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.
即 1、高层模块不应该依赖低层模块,两者都应该依赖于抽象(抽象类或接口)
2、抽象(抽象类或接口)不应该依赖于细节(具体实现类)
3、细节(具体实现类)应该依赖抽象
2.理解:
低层模块:不可分割的原子逻辑;
高层模块:低层模块的再组合;
抽象: 接口或抽象类(特点:不能直接被实例化);
细节: 与接口或抽象类对应的实现类(特点:可以直拉被new实例化);
据此,DIP在Java语言中的表现就是:
- 模块间的依赖通过抽象类或接口发生,实现类之间的依赖关系也是通过抽象类或接口产生(实现类之间不应发生直接的依赖关系);
- 接口或抽象不依赖于实现类,但实现类依赖接口或抽象类;
再次理解DIP:
依赖倒置原则 要求"高层模块不应该依赖于低层模块,二者都应该依赖于抽象。"这一原则在分层架构模式中,得到了淋漓尽致地运用。例如,业务逻辑层(高层模块)的对象就不应该直接依赖于数据访问层(低层模块)的具体实现对象,而应该通过数据访问层的抽象接口进行访问,如下图所示。如果高层模块直接依赖于低层模块,一旦低层模块发生变化,就会影响到高层模块。通过引入抽象,对于高层模块而言,低层模块的实现是可替换的。这实际上也是"开放封闭原则"的体现。这一原则同时还体现了软件设计对"间接"的追求。下图中的数据访问抽象层就是在设计中引入的一层间接性。
依赖倒置原则还要求"抽象不应该依赖于细节,细节应该依赖于抽象"。这与之前的要求一脉相承。关键仍然是"抽象",抽象属于高层,细节属于低层,低层依赖于高层,而不是高层依赖于低层,这正是依赖倒置的真谛。依赖倒置原则与"面向接口编程"的思想不谋而合。GOF在《设计模式》一书中旗帜鲜明地提出了面向对象设计的首要原则,那就是"针对接口编程,而不是针对实现编程"。因为客户程序关心的仅仅是对象提供什么功能,而不是功能如何实现,甚至不关心对象的具体类型。这就好像电源插头只关心插座是两相还是三相,而无需知道插头如何与插座内的电线相连。
依赖正置:类间的依赖是实实在在的实现类间的依赖,也就是面向实现编程。这也是正常人的思维方式,比如要开奔驰就开奔驰(而没考虑宝马)。
依赖倒置:编写程序需要的是对现实世界的事物进行抽象,抽象的结果就是有了抽象类和接口,然后我们根据系统设计的需要产生了抽象间的依赖,代替了人们传统思维中的事物间的依赖,“倒置”便由此而生。
3.问题由来:
类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。[解决方案]将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。
4.使用DIP的好处:
- 可以通过抽象使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合(也是本质);
- 可以规避一些非技术因素引起的问题(如项目大时,需求变化的概率也越大,通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束,可以减少需求变化引起的工作量剧增情况。同时,发生人员变动,只要文档完善,也可让维护人员轻松地扩展和维护);
- 可以促进并行开发(如,两个类之间有依赖关系,只要制定出两者之间的接口(或抽象类)就可以独立开发了,而且项目之间的单元测试也可以独立地运行,而TDD开发模式更是DIP的最高级应用(特别适合项目人员整体水平较低时使用))。
5.难点:
- DIP是6大原则中最难以实现的原则,它是实现开闭原则的重要途径,DIP没有实现,就别想实现对扩展开放,对修改关闭。在项目中只要记住“面向接口编程”就基本上抓住了DIP的核心。
- 使用此原则时要审时度势,每个原则的优点都是有限度的,所以别为一个原则而放弃了终极目标:投产上线和盈利。
6.实践建议:
- 每个类尽量都有接口或抽象类,或者二者都有;(有了抽象才可能DIP)
- 变量的声明类型尽量是接口或抽象类;(工具类一般不需要)
-
任何类都不应该从具体类派生;(如果项目处于开发状态,就不应该有这种情况,当然,设计缺陷在所难免,因此不要超过两层的继承。但对于项目维护者来说,可以不用考虑这个规则,因为维护工作基本上都是进行扩展开发,修复行为,通过一个继承关系,覆写一个方法就可以修正一个很大的bug,何必去继承最高的基类呢?(当然不应该轻易继承,之所以要这样,是因为可能不甚了解父类或者无法获得父类的代码))
-
尽量不要覆写基类的方法(如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。)
-
结合里氏替换原则使用(上一个章节中我们讲解了里氏替换原则,父类出现的地方子类就能出现,再结合本章节的讲解,我们可以得出这样一个通俗的规则: 接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。)
7.依赖的三种写法:
依赖是可以传递的,只要做到抽象依赖,即使是多层的依赖传递也无所畏惧。
A.构造函数传递依赖对象
比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。
- public interface IDriver{
- //是司机就应该会驾驶汽车
- public void drive();
- }
- public class Driver implements IDriver{
- private ICar car;
- //构造函数注入
- public Driver(ICar _car){
- this.car = _car;
- }
- //司机的主要职责就是驾驶汽车
- public void drive(){
- this.car.run();
- }
- }
B.Setter方法传递依赖对象
即在我们设置的setXXX方法中的参数为抽象类或接口,来实现传递依赖对象
- public interface IDriver {
- //车辆型号
- public void setCar(ICar car);
- //是司机就应该会驾驶汽车
- public void drive();
- }
- public class Driver implements IDriver{
- private ICar car;
- public void setCar(ICar car){
- this.car = car;
- }
- //司机的主要职责就是驾驶汽车
- public void drive(){
- this.car.run();
- }
- }
C.接口声明依赖对象
在接口的方法中声明依赖对象,该方法也叫做接口注入。
- public interface IDriver{
- //是司机就应该会驾驶汽车
- public void drive(ICar car);
- }
- public class Driver implements IDriver{
- //司机的主要职责就是驾驶汽车
- public void drive(ICar car){
- car.run();
- }
- }
8.范例:
8.1 面对实现编程
(当然,这里为了展现出问题,当然最小需求时,可以这样。。。)
司机驾驶奔驰车类图
- //司机源代码
- public class Driver{
- //是司机就应该会驾驶汽车
- public void drive(Benz benz){//1
- benz.run();
- }
- }
- //奔驰源代码
- public class Benz{
- //汽车肯定会跑
- public void run(){
- System.out.println("奔驰汽车开始运行。。。");
- }
- }
- //场景类源代码
- public class Client{
- public static void main(String[] args){
- Driver zhangsan = new Driver();
- Benz benz = new Benz();//2
- //张三开奔驰车
- zhangsan.drive(benz);
- }
- }
但假若现在给出宝马类,发生变更呢?
- //宝马车源代码
- public class BMW{
- //汽车肯定会跑
- public void run(){
- System.out.println("宝马汽车开始运行。。。");
- }
- }
8.2 现根据DIP原则,重新编写如下:
引入DIP后的类图
下面建立两个接口:IDriver和ICar,分别定义了司机和汽车的各个职能,在IDriver中,通过传入ICar接口实现了抽象之间的依赖关系,Driver实现类也传入ICar接口,至于到底是哪个类型号的Car,需要在高层模块中声明或修正。
- 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 Benz implements ICar{
- //汽车肯定会跑
- public void run(){
- System.out.println("奔驰汽车开始运行。。。");
- }
- }
- //宝马车源代码
- public class BMW implements ICar{
- //汽车肯定会跑
- public void run(){
- System.out.println("宝马汽车开始运行。。。");
- }
- }
- //场景类源代码
- public class Client{
- public static void main(String[] args){
- Driver zhangsan = new Driver();
- Benz benz = new Benz();//可更改这里
- //张三开奔驰车
- zhangsan.drive(benz);//可更改这里
- }
- }
- //场景类源代码
- public class Client{
- public static void main(String[] args){
- Driver zhangsan = new Driver();
- BWM bwm = new BWM();
- //张三开宝马
- zhangsan.drive(bwm);
- }
- }
把变更引起的风险降低到最小。
8.3 再来思考依赖倒置对并行开发的影响。
两个类之间有依赖关系,只要制定出两者之间的接口(或抽象类)就可以独立开发了,而且项目之间的单元测试也可以独立地运行,而TDD(Test-Driven Development,测试驱动开发)开发模式就是DIP的最高级应用。
回顾上述例子,甲程序员负责IDriver的开发,乙程序员负责ICar的开发,两个开发人员只要制定好了接口,就可以独立地开发了,甲开发进度比较快, 完成了IDriver以及相关的实现类Driver的开发工作,而乙程序员滞后开发,那甲是否可以进行单元测试呢?可以,我们引入一个JMock工具,其最基本的功能就是根据抽象虚拟一个对象进行测试,测试类如下所示:- //测试类
- public class DriverTest extends TestCase{
- Mockery context = new JUnit4Mockey();
- @Test
- public void testDriver(){
- //根据接口虚拟一个对象
- final ICar car = context.mock(ICar.class);
- IDriver driver = new Driver();
- //内部类
- context.checking(new Expectations()){
- oneOf(car).run();
- });
- driver.drive(car);
- }
- }