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

第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