依赖倒转原则

最新推荐文章于 2024-08-07 14:38:07 发布

钟桓

最新推荐文章于 2024-08-07 14:38:07 发布

阅读量1.9w

点赞数 8

分类专栏：跟着ZHONGHuan学习设计模式系列跟着ZHONGHuan学习设计模式文章标签：设计模式依赖倒转原则 DIP

本文链接：https://blog.csdn.net/zhonghuan1992/article/details/38014911

版权

跟着ZHONGHuan学习设计模式系列同时被 2 个专栏收录

23 篇文章 1 订阅

订阅专栏

跟着ZHONGHuan学习设计模式

23 篇文章 30 订阅

订阅专栏

转载请注明出处！！！http://blog.csdn.net/zhonghuan1992

所有配套代码均在github上：https://github.com/ZHONGHuanGit/DesignPattern

跟着ZHONGHuan学习设计模式

依赖倒转原则

依赖：

DIP（DependenceInversion Principal），再说这个原则之前，我们先说说什么是依赖吧。这里的依赖关系我们理解为UML关系中的依赖。简单的说就是A use a B，那么A对B产生了依赖。具体请看下面的例子。

图一

从上面的途中我们可以看到，类A的方法func中用到了B，其实我们可以就这么理解，当A中用到了B，那么我们就说A对B产生了依赖，不过请你注意下，不是声明了就是，请看下面的，这种关系叫做零耦合关系，具体可以看下面依赖关系分类。

图2

依赖关系种类：

1）零耦合关系：如果两个类之间没有耦合关系，称之为零耦合

图3:零耦合

2）具体耦合关系：具体耦合发生在两个具体类（可实例化的）之间，经由一个类对另一个类的直接引用造成。

图3:具体耦合

3）抽象耦合关系：抽象耦合关系发生在一个具体类和一个抽象类（或者java接口）之间，使两个必须发生关系的类之间存在最大的灵活性。

图4:抽象耦合

什么是依赖倒转原则

简单的说，依赖倒转原则就是要求客户端依赖于抽象耦合，依赖倒转原则的表述是：抽象应当不依赖细节，细节应当依赖于抽象。（Abstractions should not depend upon details， detailsshould depend upon abstractions）

依赖倒转原则的另一种表述是：要针对接口编程，不要针对实现编程。（Program to an interface， not animplementation）

针对接口编程的意思就是说，应当使用java接口或者抽象java类进行变量的类型声明，参数的类型声明，方法的返回类型说明，以及数据类型的转换等。通俗点说，就是实现类只是实现实现的接口或者继承的抽象类中的方法，不要再声明新的变量或者新的方法，这样能够保证实现依赖倒转原则，当然这样有时也并不是好的方式，该原则是在合适的时候使用。

从实例中体会依赖倒转原则

依赖倒置原则的核心思想是面向接口编程，我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。代码如下：

1.	class Book{  
2.	    public String getContent(){  
3.	        return "很久很久以前有一个阿拉伯的故事……";  
4.	    }  
5.	}  
6.	  
7.	class Mother{  
8.	    public void narrate(Book book){  
9.	        System.out.println("妈妈开始讲故事");  
10.	        System.out.println(book.getContent());  
11.	    }  
12.	}  
13.	  
14.	public class Client{  
15.	    public static void main(String[] args){  
16.	        Mother mother = new Mother();  
17.	        mother.narrate(new Book());  
18.	    }  
19.	}

运行结果：

妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……

运行良好，假如有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码如下：

[java] view plain copy

1. class Newspaper{

2. public String getContent(){

3. return "林书豪38+7领导尼克斯击败湖人……";

4. }

5. }

这位母亲却办不到，因为她居然不会读报纸上的故事，这太荒唐了，只是将书换成报纸，居然必须要修改Mother才能读。假如以后需求换成杂志呢？换成网页呢？还要不断地修改Mother，这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了，必须降低他们之间的耦合度才行。

我们引入一个抽象的接口IReader。读物，只要是带字的都属于读物：

[java] view plain copy

1. interface IReader{

2. public String getContent();

3. }

Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：

[java] view plain copy

1. class Newspaper implements IReader {

2. public String getContent(){

3. return "林书豪17+9助尼克斯击败老鹰……";

4. }

5. }

6. class Book implements IReader{

7. public String getContent(){

8. return "很久很久以前有一个阿拉伯的故事……";

9. }

10. }

11.

12. class Mother{

13. public void narrate(IReader reader){

14. System.out.println("妈妈开始讲故事");

15. System.out.println(reader.getContent());

16. }

17. }

18.

19. public class Client{

20. public static void main(String[] args){

21. Mother mother = new Mother();

22. mother.narrate(new Book());

23. mother.narrate(new Newspaper());

24. }

25. }

运行结果：

妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
妈妈开始讲故事
林书豪17+9助尼克斯击败老鹰……

这样修改后，无论以后怎样扩展Client类，都不需要再修改Mother类了。这只是一个简单的例子，实际情况中，代表高层模块的Mother类将负责完成主要的业务逻辑，一旦需要对它进行修改，引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。

采用依赖倒置原则给多人并行开发带来了极大的便利，比如上例中，原本Mother类与Book类直接耦合时，Mother类必须等Book类编码完成后才可以进行编码，因为Mother类依赖于Book类。修改后的程序则可以同时开工，互不影响，因为Mother与Book类一点关系也没有。参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。

上述实例引用自这里http://blog.csdn.net/zhengzhb/article/details/7289269