桥梁模式（Bridge Pattern）

一、 桥梁（Bridge）模式 

桥梁模式是一个非常有用的模式，也是比较复杂的一个模式。熟悉这个模式对于理解面向对象的设计原则，包括"开－闭"原则(OCP)以及组合/聚合复用原则(CARP)都很有帮助。理解好这两个原则，有助于形成正确的设计思想和培养良好的设计风格。注：《Java 与模式》一书认为 Bridge模式不是一个使用频率很高的模式，我不太赞同，我认为 Bridge模式中蕴涵了很多设计模式的关键思想在里面，所以我这里采纳了《Design Patterns Explained》一书的作者 Alan Shalloway与 James R. Trott的观点：The Bridge pattern is quite a bit more complex than the other patterns you just learned; it is also much more useful.

 桥梁模式的用意 【GOF95】在提出桥梁模式的时候指出，桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。这句话有三个关键词，也就是抽象化、实现化和脱耦。

 抽象化 

存在于多个实体中的共同的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当做同样的实体对待【LISKOV94】。

 实现化

 抽象化给出的具体实现，就是实现化。

脱耦 

所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的用意。

二、 桥梁模式的结构 

桥梁模式【GOF95】是对象的结构模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。 下图所示就是一个实现了桥梁模式的示意性系统的结构图。 

可以看出，这个系统含有两个等级结构，也就是：

 1.  由抽象化角色和修正抽象化角色组成的抽象化等级结构。

 2.  由实现化角色和两个具体实现化角色所组成的实现化等级结构。 桥梁模式所涉及的角色有： 

抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。 

修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。  

实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。 

具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。 

三、 调制解调器问题 

感觉《敏捷软件开发－原则、模式与实践》中关于 Bridge 模式的例子很好。（《Java 与模式》一书 33 章的对变化的封装一节也写得很不错，推荐大家读一读。它深入的阐述了《Design Patterns Explained》一书中"1）Design to interfaces. 2)Favor composition over inheritance. 3)Find what varies and encapsulate it"的三个观点。）。

如图所示，有大量的调制解调器客户程序在使用 Modem接口。Modem接口被几个派生类 HayesModem、USRoboticsModem和 EarniesModem实现。它很好地遵循了 OCP、LSP 和DIP。当增加新种类的调制解调器时，调制解调器的客户程序不会受影响。 假定这种情形持续了几年，并有许多调制解调器的客户程序都在使用着 Modem 接口。现出现了一种不拨号的调制解调器，被称为专用调制解调器。它们位于一条专用连接的两端。有几个新应用程序使用这些专用调制解调器，它们无需拨号。我们称这些使用者为 DedUser。但是，客户希望当前所有的调制解调器客户程序都可以使用这些专用调制解调器。他们不希望去更改许许多多的调制解调器客户应用程序，所以完全可以让这些调制解调器客户程序去拨一些假(dummy)电话号码。如果能选择的话，我们会把系统的设计更改为下图所示的那样。 

我们把拨号和通信功能分离为两个不同的接口。原来的调制解调器实现这两个接口，而调制解调器客户程序使用这两个接口。DedUser只使用 Modem接口，而 DedicateModem 只实现Modem 接口。但这样做会要求我们更改所有的调制解调器客户程序--这是客户不允许的。 

一个可能的解决方案是让 DedicatedModem 从 Modem派生并且把 dial 方法和 hangup 方法实现为空，就像这样： 

几个月后，已经有了大量的DedUser，此时客户提出了一个新的更改。为了能拨国际电话号码、信用卡电话等，必修对现有 dial 中使用char[10]存储号码改为能够拨打任意长度的电话号码。显然，所有的调制解调器客户程序都必须更改。客户同意了对调制解调器客户程序的更改，因为他们别无选择。糟糕的是，现在必须要去告诉 DedUser 的编写者，他们必须要更改他们的代码！你可以想象他们听到这个会有多高兴。本来他们是不用调用 dial 的。这就是许多项目都会具有的那种有害的混乱依赖关系。系统某一部分中的一个杂凑体(kludge)创建了一个有害的依赖关系，最终导致系统中完全无关的部分出现问题。如果使用ADAPTER模式解决最初的问题的话，就可以避免这个严重问题。如图： 

请注意，杂凑体仍然存在。适配器仍然要模拟连接状态。然而，所有的依赖关系都是从适配器发起的。杂凑体和系统隔离，藏身于几乎无人知晓的适配器中。

 BRIDGE模式 

看待这个问题，还有另外一个方式。现在，出现了另外一种切分 Modem 层次结构的方式。如下图： 

这不是一个理想的结构。每当增加一款新硬件时，就必须创建两个新类--一个针对专用的情况，一个针对拨号的情况。每当增加一种新连接类型时，就必须创建3 个新类，分别对应 3款不同的硬件。如果这两个自由度根本就是不稳定的，那么不用多久，就会出现大量的派生类。在类型层次结构具有多个自由度的情况中，BRIDGE模式通常是有用的。我们可以把这些层次结构分开并通过桥把它们结合到一起，而不是把它们合并起来。如图：

我们把调制解调器类层次结构分成两个层次结构。一个表示连接方法，另一个表示硬件。 这个结构虽然复杂，但是很有趣。它的创建不会影响到调制解调器的使用者，并且还完全分离了连接策略和硬件实现。ModemConnectController的每个派生类代表了一个新的连接策略。在这个策略的实现中可以使用sendlmp、 receivelmp、diallmp和 hanglmp。新 imp方法的增加不会影响到使用者。可以使用 ISP 来给连接控制类增加新的接口。这种做法可以创建出一条迁移路径，调制解调器的客户程序可以沿着这条路径慢慢地得到一个比 dial和hangup层次更高的 API。

四、 在什么情况下应当使用桥梁模式 

根据上面的分析，在以下的情况下应当使用桥梁模式：   

• 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
•   设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
•     一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
•     虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。 

James W. Cooper，《C#设计模式》