敏捷软件开发 - 原则、模式与实践 —— 设计模式（九）ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。

本文对应原书第25章

ABSTRACT SERVER模式

图1

如上图在Switch和Light之间引入一个接口，这样就使得Switch能够控制任何实现了这个接口的东西。这立即就满足了DIP和OCP。这个就是ABSTRACT SERVER模式。

请注意接口的名字是从它的客户的角度起的。它被称为Switchable而不是ILight。我们在前面已经讨论过这个问题，并且可能还会再次看到它。接口属于它的客户，而不是它的派生类。客户和接口之间的逻辑绑定关系要强于接口和它的派生类之间的逻辑绑定关系。它们之间的关系强到在没有Switchable的情况下就无法使用Switch；但是，在没有Light的情况下却完全可以使用Switch。逻辑关系的强度和实体关系的强度是不一致的。继承是一个比关联强得多的实体关系。

ADAPTER模式

图2

上图是一个ADAPTER模式例子。Modem接口有4个方法，新加入一种专线型调试解调器，它无需拨号和挂断，使用专线型调试解调器的客户程序称为DedUser，同时又希望现有客户程序也可以使用这种新型调试解调器。在这个例子中，DedicatedModem不从Modem继承。DedUser客户程序通过DedicatedModemAdapter间接地使用DedicatedModem。在这个适配器的dial和hangup实现中去模拟链接状态。它把send和receive调用委托给DedicatedModem。

BRIDGE模式

Modem问题，还有另外一个方式。对于专用Modem的需要向Modem类型层次结构中增加一个新的自由度。在最初构思Modem类型时，它只是一组不同硬件设备的接口。因此，我们让HayesModem、USModem和ErniesModem从基类Modem派生。但是，现在，出现了另外一种切分Modem层次结构的方式。我们可以让DialModem和DedicatedModem从Modem派生。

在类型层次结构具有多个自由度的情况中，BRIDGE模式通常是有用的。我们可以把这些层次结构分开并通过桥把它们结合在一起，而不是把它们合并起来。

图3

上图展示了这个结构。我们把Modem类层次结构分成两个层次结构。一个表示连接方法，另一个表示硬件。

Modem的使用者继续使用Modem接口，ModemConnectionController实现了Modem接口。ModemConnectionController的派生类控制着连接机制。DialModemController的dial方法和hangup方法只是转调用基类ModemConnectionController中的dialImp和hangupImp。接着，这两个方法把调用委托给类ModemImplementation，在那里它们会被分派到适当的硬件控制器。DedModemController把dial和hangup实现为模拟连接状态。它的send和receive会转调用sendImp和receiveImp，并像前面一样再委托给ModemImplementation层次结构。

请注意，ModemConnectionController基类中的4个imp方法都是受保护的。这是因为它们只被ModemConnectionController的派生类使用。其他任何类都不应当调用它们。

结论

使用ADAPTER模式的解决方案是简单和直接的。它让所有的依赖关系都指向正确的方向，并且实现起来非常简单。BRIDGE模式稍微有些复杂。我建议在开始时不要使用BRIDGE模式，直到你明显可以看出需要完全分离连接策略和通讯策略并且需要增加新的连接策略时，才使用这种方法。

完整内容请查看敏捷软件开发 - 原则、模式与实践系列