设计模式六大原则(3):依赖倒置原则

 

依赖倒置原则

 

设计模式系列文章

1、问题由来

  类A直接依赖于类B,假如要将类A修改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑。类B和C是底层模块,负责基本的原子操作。假如修改类A,将会给程序带来不必要的风险。而遵循依赖倒置原则的程序设计可以解决这一问题。

2、什么是依赖倒置原则

  英文缩写DIP(Dependence Inversion Principle)。

  原始定义: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.

  翻译过来就三层含义:

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

  抽象:即抽象类或接口,两者是不能够实例化的。

  细节:即具体的实现类,实现接口或者继承抽象类所产生的类,两者可以通过关键字new直接被实例化。

  现在我们来通过实例还原开篇问题的场景,以便更好的来理解。下面代码描述了一个简单的场景,Jim作为人有吃的方法,苹果有取得自己名字的方法,然后实现Jim去吃苹果。

  代码如下:

//具体Jim人类
public class Jim {
	public void eat(Apple apple){
		System.out.println("Jim eat " + apple.getName());
	}
}
//具体苹果类
public class Apple {
	public String getName(){
		return "apple";
	}
}
public class Client {
	public static void main(String[] args) {
		Jim jim = new Jim();
		Apple apple = new Apple();
		jim.eat(apple);
	}
}

  运行结果:Jim eat apple

  上面代码看起来比较简单,但其实是一个非常脆弱的设计。现在Jim可以吃苹果了,但是不能只吃苹果而不吃别的水果啊,这样下去肯定会造成营养失衡。现在想让Jim吃香蕉了(好像香蕉里含钾元素比较多,吃点比较有益),突然发现Jim是吃不了香蕉的,那怎么办呢?看来只有修改代码了啊,由于上面代码中Jim类依赖于Apple类,所以导致不得不去改动Jim类里面的代码。那如果下次Jim又要吃别的水果了呢?继续修改代码?这种处理方式显然是不可取的,频繁修改会带来很大的系统风险,改着改着可能就发现Jim不会吃水果了。

  上面的代码之所以会出现上述难堪的问题,就是因为Jim类依赖于Apple类,两者是紧耦合的关系,其导致的结果就是系统的可维护性大大降低。要增加香蕉类却要去修改Jim类代码,这是不可忍受的,你改你的代码为什么要动我的啊,显然Jim不乐意了。我们常说要设计一个健壮稳定的系统,而这里只是增加了一个香蕉类,就要去修改Jim类,健壮和稳定还从何谈起。

  而根据依赖倒置原则,我们可以对上述代码做些修改,提取抽象的部分。首先我们提取出两个接口:People和Fruit,都提供各自必需的抽象方法,这样以后无论是增加Jim人类,还是增加Apple、Banana等各种水果,都只需要增加自己的实现类就可以了。由于遵循依赖倒置原则,只依赖于抽象,而不依赖于细节,所以增加类无需修改其他类。

  代码如下:

//人接口
public interface People {
	public void eat(Fruit fruit);//人都有吃的方法,不然都饿死了
}
//水果接口
public interface Fruit {
	public String getName();//水果都是有名字的
}
//具体Jim人类
public class Jim implements People{
	public void eat(Fruit fruit){
		System.out.println("Jim eat " + fruit.getName());
	}
}
//具体苹果类
public class Apple implements Fruit{
	public String getName(){
		return "apple";
	}
}
//具体香蕉类
public class Banana implements Fruit{
	public String getName(){
		return "banana";
	}
}
public class Client {
	public static void main(String[] args) {
		People jim = new Jim();
		Fruit apple = new Apple();
		Fruit Banana = new Banana();//这里符合了里氏替换原则
		jim.eat(apple);
		jim.eat(Banana);
	}
}

  运行结果:

  Jim eat apple
  Jim eat banana

  • People类是复杂的业务逻辑,属于高层模块,而Fruit是原子模块,属于低层模块。People依赖于抽象的Fruit接口,这就做到了:高层模块不应该依赖低层模块,两者都应该依赖于抽象(抽象类或接口)。
  • People和Fruit接口与各自的实现类没有关系,增加实现类不会影响接口,这就做到了:抽象(抽象类或接口)不应该依赖于细节(具体实现类)。
  • Jim、Apple、Banana实现类都要去实现各自的接口所定义的抽象方法,所以是依赖于接口的。这就做到了:细节(具体实现类)应该依赖抽象。

3、什么是倒置

  到了这里,我们对依赖倒置原则的“依赖”就很好理解了,但是什么是“倒置”呢。是这样子的,刚开始按照正常人的一般思维方式,我想吃香蕉就是吃香蕉,想吃苹果就吃苹果,编程也是这样,都是按照面向实现的思维方式来设计。而现在要倒置思维,提取公共的抽象,面向接口(抽象类)编程。不再依赖于具体实现了,而是依赖于接口或抽象类,这就是依赖的思维方式“倒置”了。

4、依赖的三种实现方式

  对象的依赖关系有三种方式来传递:

  • 接口方法中声明依赖对象。就是我们上面代码所展示的那样。
  • 构造方法传递依赖对象。在构造函数中的需要传递的参数是抽象类或接口的方式实现。代码如下:
//具体Jim人类
public class Jim implements People{
	
	private Fruit fruit;
	
	public Jim(Fruit fruit){//构造方法传递依赖对象
		this.fruit = fruit;
	}
	
	public void eat(Fruit fruit){
		System.out.println("Jim eat " + this.fruit.getName());
	}
}
  • Setter方法传递依赖对象。在我们设置的setXXX方法中的参数为抽象类或接口,来实现传递依赖对象。代码如下:
//具体Jim人类
public class Jim implements People{
	
	private Fruit fruit;
	
	public void setFruit(Fruit fruit){//setter方式传递依赖对象
		this.fruit = fruit;
	}
	
	public void eat(){
		System.out.println("Jim eat " + this.fruit.getName());
	}
}

5、优点

  从上面的代码修改过程中,我们可以看到由于类之间松耦合的设计,面向接口编程依赖抽象而不依赖细节,所以在修改某个类的代码时,不会牵涉到其他类的修改,显著降低系统风险,提高系统健壮性。

  还有一个优点是,在我们实际项目开发中,都是多人团队协作,每人负责某一模块。比如一个人负责开发People模块,一人负责开发Fruit模块,如果未采用依赖倒置原则,没有提取抽象,那么开发People模块的人必须等Fruit模块开发完成后自己才能开发,否则编译都无法通过,这就是单线程的开发。为了能够两人并行开发,设计时遵循依赖倒置原则,提取抽象,就可以大大提高开发进度。

6、总结

  说到底,依赖倒置原则的核心就是面向接口编程的思想,尽量对每个实现类都提取抽象和公共接口形成接口或抽象类,依赖于抽象而不要依赖于具体实现。依赖倒置原则的本质其实就是通过抽象(抽象类或接口)使各个类或模块的实现彼此独立,不相互影响,实现模块间的松耦合。但是这个原则也是6个设计原则中最难以实现的了,如果没有实现这个原则,那么也就意味着开闭原则(对扩展开放,对修改关闭)也无法实现。

 

posted @ 2013-03-19 08:46 OpenFire_ 阅读(...) 评论(...) 编辑 收藏