软件设计原则----依赖倒置原则（DIP）

"要依赖于抽象，不要依赖于具体。”

“要针对接口编程，不要针对实现编程。”

陈述：

高层模块不应该依赖于低层模块。二者应该依赖于抽象。
抽象不应该依赖于细节。细节应该依赖于抽象。

分析：

所谓“倒置”是相对于传统的开发方法（例如结构化方法）中总是倾向于让高层模块依赖于低层模块而言的软件结构而言的。
高层包含应用程序的策略和业务模型，而低层包含更多的实现细节，平台相关细节等。高层依赖低层将导致：
- 难以复用。通常改变一个软硬件平台将导致一些具体的实现发生变化，如果高层依赖低层，这种变化将导致逐层的更改。
- 难以维护。低层通常是易变的。

层次化：

“……所有良构的OO体系结构都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。”

——Booch

对上述论述可能存在两种不同的理解：

简单的理解

更好的理解

1)依赖关系倒置
下层的实现，依赖于上层的接口

2)接口所有权倒置
客户拥有接口，而服务者则从这些接口派生

我们可以分两种模式来定义：

1、依赖不倒置的开发：自顶向下首先设计整个软件的分解结构，然后首先实现下层的功能，再实现上层的功能，并使上层调用下层函数。

2、依赖倒置的开发：首先设计上层需要调用的接口，并实现上层，然后低层类从上层接口派生，实现低层。在这种情况下，接口属于上层。

实例

我们来看一下Button与Lamp：

Button（开关）感知外界的变化。
当接受到Poll（轮询）消息时，判断其是否被“按下”。这个按下是抽象的（不关心通过什么样的机制去感知）：

可能是GUI上的一个按钮被鼠标单击。
可能是一个真正的按钮被手指按下。
可能是一个防盗装置检测到了运动。
……

Lamp（灯）根据指示，收到turn on消息显示某种灯光，收到turn off消息关闭灯光

可能是计算机控制台的LED。
可能是停车场的日光灯。
可能是激光打印机中的激光。
……

应该如何设计程序来用Button控制Lamp呢？

初步设计

Button对象直接依赖Lamp对象，从而：

Lamp的任何变化都会影响到Button，导致其改写或者重新编译。
黑盒方式复用Button来控制一个Motor类变得不可能。

[cpp] view plain copy print ?

classButton{
Lamp*itsLamp;
public:
voidpoll(){
if(/*somecondition*/)
itsLamp->turnOn();
....
}
}；

class Button{
	Lamp * itsLamp;
public:
	void poll( ){
		if(/* some condition */)
			itsLamp->turnOn( );
		....
	}
}；

问题
上面的设计违反了DIP。应用程序的高层策略没有和低层实现分离；抽象没有和具体细节分离。

改进思路
依赖于抽象
什么是高层策略？就是应用背后的抽象----背后的抽象是检测用户的开/关指令：

用什么机制检测用户的指令？无关紧要。
目标对象是什么？无关紧要。
他们不会影响到抽象的具体细节。

改进后的设计：

Button依赖于抽象的接口ButtonServer（向该接口发消息）。ButtonServer提供一些抽象的方法，Button类通过这些接口可以开启或关掉一些东西。

Lamp也依赖于ButtonServer接口（从此接口派生），提供具体的实现。

如下图所示：

部分代码：

[cpp] view plain copy print ?

//Button.h
#include"ButtonServer.h"
classButton{
ButtonServer*bs;
public:
voidpoll();
};
//Button.cpp
voidButton::poll(){
if(/*mechanismfordetectingturnOncommand*/)
bs->turnOn();
elseif((/*mechanismfordetectingturnOffcommand*/)
bs->turnOff();
}

//Button.h
#include "ButtonServer.h"

class Button{
	ButtonServer * bs;
public:
	void poll( );
};

//Button.cpp
void Button::poll( ){
	if(/* mechanism for detecting turnOn command */)
			bs->turnOn( );
	else if((/* mechanism for detecting turnOff command */)
			bs->turnOff( );
}

[cpp] view plain copy print ?

//ButtonServer.h
classButtonServer{
public:
<spanstyle="white-space:pre;">virtualvoidturnOn()=0;
<spanstyle="white-space:pre;">virtualvoidturnOff()=0;
};
//lamp.h
classLamp:publicButtonServer{
public:
<spanstyle="white-space:pre;">voidturnOn();
<spanstyle="white-space:pre;">voidturnOff();
};
//lamp.cpp
voidLamp::turnOn(){
<spanstyle="white-space:pre;">/*codesforturnonaspecificdevice*/
}
voidLamp::turnOff(){
<spanstyle="white-space:pre;">/*codesforturnoffaspecificdevice*/
}

//ButtonServer.h
class ButtonServer{
public:
<span style="white-space: pre;">	</span>virtual void turnOn()=0;
<span style="white-space: pre;">	</span>virtual void turnOff()=0;
};


//lamp.h
class Lamp:public ButtonServer{
public:
<span style="white-space: pre;">	</span>void turnOn();
<span style="white-space: pre;">	</span>void turnOff();
};


//lamp.cpp
void Lamp::turnOn(){
<span style="white-space: pre;">	</span>/*codes for turn on a specific device*/
}


void Lamp::turnOff(){
<span style="white-space: pre;">	</span>/*codes for turn off a specific device*/
}

分析
上述设计使得Button可以控制所有愿意实现ButtonServer接口的设备，甚至是一个尚未开发出来的设备。

质疑：
这样的设计是不是强加了这样一个约束——所有需要被Button控制的对象一定要实现ButtonServer类。
如果我的设备还希望能够被另一个对象控制，比如Switch控制，怎么办？
这种设计是不是将Button对Lamp的依赖转嫁成了Lamp对Button的依赖呢？（毕竟Lamp只能被一种Button控制也是不好的）

抗辩：
上述质疑不成立。Button依赖于ButtonServer接口，但是接口并不依赖于Button，也就是说任何知道如何操作ButtonServer接口的对象都可以操作Lamp。
也许需要改进的仅仅是ButtonServer这样一个有些“误导性”的名字，我们可以将这个名字该得更加抽象一些，例如：SwitchableDevice

总结

使用传统过程化设计所创造出来的依赖关系结构，策略是依赖于细节的。----策略受细节改变影响
面向对象程序设计倒置了依赖关系结构，使细节和策略都依赖于抽象，成为面向对象设计的标志。
依赖倒置原则是实现面向对象技术的基本低层机制，有利于复用和维护。
依赖倒置原则假定具体类都是会变化的，避免对具体类的直接引用，可能会导致大量的类。功能强大，最不容易实现。

相应设计模式：
Factory Method
Prototype
Iterator

参考资源：

《设计模式：可复用面向对象软件的基础》，ERICH GAMMA RICHARD HELM RALPH JOHNSON JOHN VLISSIDES著作，李英军马晓星蔡敏刘建中译，机械工业出版社，2005.6

《敏捷软件开发：原则、模式与实践》，Robert C. Martin著，邓辉译，清华大学出版社，2003.9

《设计模式解析》，Alan Shalloway等著（徐言声译），人民邮电出版社，2006.10

原文链接：https://www.f2er.com/javaschema/285283.html

软件设计原则----依赖倒置原则（DIP）

猜你在找的设计模式相关文章