设计模式六大原则 - 依赖倒置原则

前端之家收集整理的这篇文章主要介绍了设计模式六大原则 - 依赖倒置原则前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

原文链接http://tianweili.github.io/blog/2015/02/07/dependence-inversion-principle/

什么是依赖倒置原则

英文缩写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去吃苹果。

代码如下:

     
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
     
     
//具体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等各种水果,都只需要增加自己的实现类就可以了。由于遵循依赖倒置原则,只依赖于抽象,而不依赖于细节,所以增加类无需修改其他类。

代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
     
     
//人接口
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);
}
}

运行结果:

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

什么是倒置

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

依赖的三种实现方式

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

接口方法中声明依赖对象。

就是我们上面代码所展示的那样。

构造方法传递依赖对象。

在构造函数中的需要传递的参数是抽象类或接口的方式实现。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
     
     
//具体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());
}
}

优点

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

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

总结

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


作者:李天炜

原文链接http://tianweili.github.io/blog/2015/02/07/dependence-inversion-principle/

转载请注明作者及出处,谢谢。

原文链接:https://www.f2er.com/javaschema/282973.html

猜你在找的设计模式相关文章