vlambda博客
学习文章列表

敏捷开发_依赖导致原则

所谓依赖倒置原则,就是不论高层组件和低层组件都应该依赖于抽象,而不是具体实现类。听起来更像是“针对接口编程,而不是针对实现编程”,但是这里依赖倒置原则更强调“抽象”的概念,不要让高层组件依赖低层组件,更不能依赖具体实现类,都要依赖于抽象。依赖倒置原则的核心在于“面向接口编程”,目的在于”解耦“。

倒置




依赖倒置原则中的倒置是指我们的思想要和一般的“自顶向下”结构化设计思想相反。面向过程的设计方法是从顶端分析,然后到实现类,例如,简单工厂模式中我们让工厂生产产品,到是又不想让工厂和具体实现类存在任何关系,否则就对具体实现类产生了依赖,这是我们不希望看到的结果。这时候我们就应该将思想倒置一下,不要从顶端开始,我们从具体的实现类开始,看看能够抽象出什么,然后一切都依赖抽象来进行,这样就与我们的目标相近了

依赖的三种写法

     依赖是可以传递的,A对象依赖B对象,B又依赖C,C又依赖D…,生生不息,依赖不止,记住一点:只要做到抽象依赖,即使是多层的依赖传递也无所畏惧!


敏捷开发_依赖导致原则


     对象的依赖关系有三种方式来传递,如下所示。

·        构造函数传递依赖对象

     在类中通过构造函数声明依赖对象,按照依赖注入的说法这种方式叫做构造函数注入,按照这种方式的注入,IDriver和Driver的程序修改后如代码清单3-11所示。

代码清单3-11 构造函数传递依赖对象

 


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();

}

}

·        Setter方法传递依赖对象

     在抽象中设置setter方法声明依赖关系,依照依赖注入的说法就是setter依赖注入,按照这种方式的注入,IDriver和Driver的程序修改后如代码清单3-12所示。

代码清单3-12 Setter依赖注入

 


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();

}

}

·        接口声明依赖对象

     在接口的方法中声明依赖对象,3.2章节的例子就是采用了接口声明依赖的方式,,该方法也叫做接口注入。

  This browser does not support music or audio playback. Please play it in WeChat or another browser. 敏捷开发_依赖导致原则


实例

不符合依赖倒转原则的类图


 

敏捷开发_依赖导致原则

在这幅类图中,动物工厂(高层组件)生产猫和狗(猫狗具体类属于低层组件)时就要去调用猫和狗的构造方法,当我想增加生产鱼的功能时,就要增加鱼类,还要修改动物工厂类,这就违背了开闭原则。造成这种情况的原因就是因为动物工厂过于依赖具体动物类。

 

符合依赖倒转原则的类图


 

敏捷开发_依赖导致原则

在这幅类图中,动物工厂(高层组件)生产猫和狗(猫狗具体类属于低层组件)时依然需要调用猫和狗的构造方法,但这时候因为中间增加了抽象组件,我要增加生产鱼的功能的时候只要增加鱼类和鱼工厂就行了,而不需要去修改已有的类。这符合开闭原则,增加了程序的可扩展性和可维护性。

 


 

最佳实践

     依赖倒转原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合,我们怎么在项目中使用这个规则呢?只要遵循以下的几个规则就可以:

·        每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备。

     这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置。

·        变量的显示类型尽量是接口或者是抽象类。

     很多书上说变量的类型一定要是接口或者是抽象类,这个有点绝对化了,比如一个工具类,xxxUtils一般是不需要接口或是抽象类的。还有,如果你要使用类的clone方法,就必须使用实现类,这个是JDK提供一个规范。

·        任何类都不应该从具体类派生。

     如果一个项目处于开发状态,确实不应该有从具体类派生出的子类的情况,但这也不是绝对的,因为人都是会犯错误的,有时设计缺陷是在所难免的,因此只要不超过两层的继承都是可以忍受的。特别是做项目维护的同志,基本上可以不考虑这个规则,为什么?维护工作基本上都是做扩展开发,修复行为,通过一个继承关系,覆写一个方法就可以修正一个很大的Bug,何必再要去继承最高的基类呢?

·        尽量不要覆写基类的方法。

     如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。

 

依赖倒置原则是六个设计原则中最难以实现的原则,它是实现开闭原则的重要途径,依赖倒置原则没有实现,就别想实现对扩展开放,对修改关闭。在项目中,大家只要记住是“面向接口编程”就基本上抓住了依赖倒转原则的核心。