标签：简单的 上下文 interface 地方 所有权 业务规则 客户 就会 指针
（1）高层模块不应依赖于低层模块，两者都应该依赖于抽象。
（2）抽象不应该依赖于细节，细节应该依赖于抽象。
为什么是“倒置”这个词？
这是由于许多传统的软件开发方法，比如结构化分析和设计，总是倾向于创建一些高层依赖于低层模块、策略依赖于细节的软件结构。
实际上这些方法的目的之一就是要定义程序层次结构，该层次结构描述了高层模块怎样调用低层模块。
一个设计良好的面向对象的程序，其依赖于程序结构相对于传统的过程式方法设计的通常结构而言就是被“倒置”了。
高层模块包含了一个应用程序中的重要的策略选择和业务模块。正是这些高层模块才使得其所在的应用程序区别于其他。然而，如果这些高层模块依赖于低层模块，那么低层模块的改动就会直接影响到高层模块，从而迫使它们依次做出改动。
这种情况是非常荒谬的，本应该高层的策略设置模块去影响低层的细节实现模块。包含高层业务规则的模块应该优先并独立于包含实现细节的模块。无论如何高层模块都不应该依赖于低层模块。
所有结构良好的面向对象架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供一组内聚的服务。
高层Policy使用低层的Mechanism，而Mechanism使用了更细节的Utility。这看起来似乎是正确的，然而存在一个隐伏的错误特征：
Policy对于其下一直到Utility的改动都是敏感的。这种依赖关系是传递的。Policy依赖于某些Utility层次。因此，Policy传递性地依赖于Utility。
上图展示了一个更为合适的模型，每个较高层次都为它所需要的服务声明一个抽象接口，较低的层次是吸纳了这些抽象接口，每个高层类都通过该抽象接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。这不仅解除了Policy Layer对Utility Layer的传递依赖关系，甚至也解除了Policy Layer对于Mechanism Layer的依赖关系。
请注意这里的倒置不仅仅是依赖关系的倒置，它也是接口所有权的倒置。通常会认为工具库应该拥有自己的接口。但是当应用了DIP时，往往是客户拥有抽象接口，而它们的服务者则从这些抽象接口派生。
低层模块实现了在高层模块中声明并被高层模块调用的接口。
通过这种倒置的接口所有权，对于MechanismLayer或UtilityLayer的任何改动都不会再影响到PolicyLayer。而且，PolicyLayer可以在定义了符合PolicyServiceInterface的任何上下文中重用。这样，通过倒置这些依赖关系，创建了一个更灵活、更持久、更易改变的结构。
程序中所有的依赖关系都应该终止于抽象类或接口，更这个启发式规则，可知：
（1）任何变量都不应该持有一个指向具体类的指针或引用
（2）任何类都不应该从具体类派生
（3）任何方法都不应该覆写它的任何基类中的已经实现了的方法
当然，每个程序中都会有违反该启发规则的情况，有事必须要创建具体类的实例，而创建这些实例的模块将会依赖于它们。
此外，该启发规则对于那些虽是具体但却稳定的类来说似乎不太合理。如果一个具体类不太会改变，并且也不会创建其他类似的派生类，那么依赖于它并不会造成损害。
应用程序中所编写的大多数具体类都是不稳定的。我们不想依赖于这些不稳定的具体类。通过把它们隐藏在抽象接口的后面，可以隔离它们的不稳定性。
由客户类来声明它们需要的服务接口，那么仅当客户需要时才会对接口进行改变。这样，改变实现抽象接口的类就不会影响到客户。
依赖倒置可以应用于任何存在一个类向另一个类发送消息的地方。
例如：Button对象和Lamp对象之间的情形。
Button对象感知外部环境的变化。当接收到Poll消息时，它会判断是否被用户“按下”。它不关心是通过什么样的机制去感知的。如何设计一个用Button对象控制Lamp对象的系统呢？
上图展示了一个不成熟的设计。Button对象接收Poll消息，判断按钮是否被按下，接着简单地发送turnOn或turnOff消息给Lamp对象。Button类直接依赖于Lamp类。这个依赖关系意味着当Lamp类改变时，Button类会受到影响。此外，想要重用Button来控制一个Motor对象是不可能的。在这个设计中，Button控制着Lamp对象，并且也只能控制Lamp对象。
class Button {
Lamp itsLamp;
void poll() {
itsLamp.turnOn();
}
}
这个方案违反了DIP，应用程序的高层策略没有和低层实现分离。抽象没有和具体细节分离。没有这种分离，高层策略就自动地依赖于低层模块，抽象就自动地依赖于具体细节。
什么是高层策略呢？它是应用背后的抽象，是那些不随具体细节的改变而改变的真理。
在Button/Lamp例子中，背后的抽象是检测用户的开关并将指令传给目标对象。
用什么机制检测用户的指令呢？无关紧要，目标对象是什么？同样无关紧要，这些都是不会影响到抽象的具体细
通过倒置对Lamp对象的依赖关系，可以改进设计。
可以看出Button现在和一个ButtonServer的接口关联起来。ButtonServer接口提供了一些抽象方法，Button可以使用这些方法来开启或关掉一些东西。Lamp实现了ButtonServer接口。这样，Lamp现在是依赖于别的东西了，而不是被依赖了。
设计可以使Button控制哪些愿意实现ButtonServer接口的任何设备，这赋予我们极大的灵活性。同时也意味着Button对象将能够控制还没有被创造出来的对象。
使用传统的过程化程序设计所创建出来的依赖关系结构，策略是依赖于细节的。只是糟糕的，因为这样会使策略收到细节改变的影响。面向对象的程序设计导致了依赖关系结构，使得细节和策略都依赖于抽象，并且常常是客户用于服务接口
事实上，这种依赖关系的倒置正是好的面向对象设计的标志所在。使用何种语言来编写程序时无关紧要的。如果程序的依赖关系是倒置的，它就是面向对象的设计。如果程序的依赖关系不是倒置的，它就是过程化的设计。
依赖倒置原则是实现许多面向对象技术所宣称的好处的基本低层机制。它的正确应用对于创建可重用的框架来说是必须的。同时它对于构建在变化面前富有弹性的代码也是非常重要的。由于抽象和细节被彼此距离，所以代码也非常容易维护。
标签：简单的 上下文 interface 地方 所有权 业务规则 客户 就会 指针
原文地址：https://www.cnblogs.com/lujiango/p/11549988.html
