码迷,mamicode.com
首页 > 其他好文 > 详细

敏捷软件开发:原则、模式与实践——第11章 DIP:依赖倒置原则

时间:2015-08-28 00:33:19      阅读:191      评论:0      收藏:0      [点我收藏+]

标签:

第11章 DIP:依赖倒置原则

DIP:依赖倒置原则:

a.高层模块不应该依赖于低层模块。二者都应该依赖于抽象。

b.抽象不应该依赖于细节。细节应该依赖于抽象。


11.1 层次化

  下图展示了一个简单的层次化方案:

技术分享

  高层的Policy层使用了低层的Mechanism层,而Mechanism层又使用了更细节的Utility层。它存在一个隐伏的错误特征,那就是:Policy层对于其下一直到Utility层的改动都是敏感的。依赖关系是传递的。

  下图展示了一个更为合适的模型:

技术分享

  每个较高层次都为它所需要的服务声明一个抽象接口。较低层次实现了这些接口。每个高层类都通过该接口使用下一层。这样高层就不依赖于低层。低层反而依赖于高层中声明的抽象服务接口。


11.1.1 倒置的接口所有权

  这里的倒置不仅仅是依赖关系的倒置,它也是接口所有权的倒置。我们通常会认为工具库应该拥有它们自己的接口。但是当应用了DIP时,我们发现往往是客户拥有抽象接口,而它们的服务则从这些接口派生。

  这就是著名的Hollywood原则:“Don‘t call us, we‘ll call you.(不要调用我们,我们会调用你。)” 低层模块实现了在高层模块中声明并被高层模块调用的接口。

  这里所说的所有权仅仅是指接口是随拥有它们的客户程序发布的,而非实现它们的服务器程序。接口和客户程序位于同一个包或者库中。这就迫使服务器程序库或者包依赖于客户程序库或者包。

  当然,有时我们会不想让服务器程序依赖于客户程序,特别是当有多分客户程序但是服务器却仅有一份时。在这种情况下,客户程序必须得遵循服务接口,并把它发布到一个独立的包中。


11.1.2 依赖于抽象

  程序中所有的依赖关系都应该终止于抽象类或者接口。

  • 任何变量都不应该持有一个指向具体类的引用。
  • 任何类都不应该从具体类派生。
  • 任何方法都不应该重写它的任何基类中已经实现了的方法。

  当然,每个程序都会有违反该启发规则的情况。有时必须创建具体类的实例,而创建这些实例的模块将会依赖于它们。此外,该启发规则对于那些虽然是具体但却稳定的来来说似乎不大合理。如果一个具体类不太会改变,并且也不会创建其他类似的派生类,那么依赖于它并不会造成损害。

  比如,在大多数系统中,描述字符串的类都是具体的。例如,在C#中的String。该类是稳定的。也就是说,它不太会改变。因此,直接依赖于它不会造成伤害。

  如果一个不稳定的类的接口必须变化是,这个变化一定会影响到表示该类的抽象接口。这种变化破坏了由抽象接口维系的隔离性。

  可见,该启发规则对问题的考虑有点儿简单了。另一方面,如果看得更远一点,认为是客户模块或者层来声明它们需要的服务接口,那么仅当客户需要时才会对接口进行改变。这样,改变实现抽象接口的类就不会影响到客户。


结论

  使用传统的过程化程序设计所创建出来的依赖关系结构、策略是依赖于细节的。这是糟糕的,因为这样会使策略受到细节的改变的影响。面向对象的程序设计倒置了依赖关系结构,使得细节和策略都依赖于抽象,并且常常是客户程序拥有服务接口。

  事实上,这种依赖关系倒置正是好的面向对象设计的标志所在。使用何种语言编程是无关紧要的。如程序的依赖关系是倒置的,它就是面向对象的设计。如果程序的依赖关系不是倒置的,它就是过程化的设计。

  

 

摘自:《敏捷软件开发:原则、模式与实践(C#版)》Robert C.Martin    Micah Martin 著

转载请注明出处:

作者:JesseLZJ
出处:http://jesselzj.cnblogs.com

敏捷软件开发:原则、模式与实践——第11章 DIP:依赖倒置原则

标签:

原文地址:http://www.cnblogs.com/jesselzj/p/4764975.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!