"要依赖于抽象，不要依赖于具体。”
高层模块不应该依赖于低层模块。二者应该依赖于抽象。
抽象不应该依赖于细节。细节应该依赖于抽象。
问题
上面的设计违反了DIP。应用程序的高层策略没有和低层实现分离；抽象没有和具体细节分离。
用什么机制检测用户的指令？无关紧要。
目标对象是什么？无关紧要。
他们不会影响到抽象的具体细节。
“要针对接口编程，不要针对实现编程。”
陈述：
分析：
@H_502_29@
所谓“倒置”是相对于传统的开发方法（例如结构化方法）中总是倾向于让高层模块依赖于低层模块而言的软件结构而言的。
高层包含应用程序的策略和业务模型，而低层包含更多的实现细节，平台相关细节等。高层依赖低层将导致：
@H_502_29@
难以复用。通常改变一个软硬件平台将导致一些具体的实现发生变化，如果高层依赖低层，这种变化将导致逐层的更改。
难以维护。低层通常是易变的。
层次化：
对上述论述可能存在两种不同的理解：
2)接口所有权倒置
客户拥有接口，而服务者则从这些接口派生
客户拥有接口，而服务者则从这些接口派生
我们可以分两种模式来定义：
2、依赖倒置的开发：首先设计上层需要调用的接口，并实现上层，然后低层类从上层接口派生，实现低层。在这种情况下，
接口属于上层。
实例
我们来看一下Button与Lamp：
Button（开关）感知外界的变化。
当接受到Poll（轮询）消息时，判断其是否被“按下”。这个按下是抽象的（不关心通过什么样的机制去感知）：
@H_502_29@可能是GUI上的一个按钮被鼠标单击。
可能是一个真正的按钮被手指按下。
可能是一个防盗装置检测到了运动。
……
Lamp（灯）根据指示，收到turn on消息显示某种灯光，收到turn off消息关闭灯光
@H_502_29@可能是计算机控制台的LED。
可能是停车场的日光灯。
可能是激光打印机中的激光。
……
应该如何设计程序来用Button控制Lamp呢？
当接受到Poll（轮询）消息时，判断其是否被“按下”。这个按下是抽象的（不关心通过什么样的机制去感知）：
@H_502_29@
@H_502_29@
初步设计
- classButton{
- Lamp*itsLamp;
- public:
- voidpoll(){
- if(/*somecondition*/)
- itsLamp->turnOn();
- ....
- }
- }；
上面的设计违反了DIP。应用程序的高层策略没有和低层实现分离；抽象没有和具体细节分离。
改进思路
依赖于抽象
什么是高层策略？就是应用背后的抽象----背后的抽象是检测用户的开/关指令：
改进后的设计：
Button依赖于抽象的接口ButtonServer（向该接口发消息）。ButtonServer提供一些抽象的方法，Button类通过这些接口可以开启或关掉一些东西。
Lamp也依赖于ButtonServer接口（从此接口派生），提供具体的实现。
如下图所示：
部分代码：
?
- //Button.h
- #include"ButtonServer.h"
- classButton{
- ButtonServer*bs;
- public:
- voidpoll();
- };
- //Button.cpp
- voidButton::poll(){
- /*mechanismfordetectingturnOncommand*/)
- bs->turnOn();
- elseif((/*mechanismfordetectingturnOffcommand*/)
- bs->turnOff();
- }
