桥接（bridge) 模式--结构型模式之五

1. 意图
     将抽象部分与它的实现部分分离,使它们都可以独立地变化。
2. 别名
Handle/Body
3. 动机
        当一个抽象可能有多个实现时,通常用继承来协调它们。抽象类定义对该抽象的接口,
而具体的子类则用不同方式加以实现。但是此方法有时不够灵活。继承机制将抽象部分与它
的实现部分固定在一起,使得难以对抽象部分和实现部分独立地进行修改、扩充和重用。
      让我们考虑在一个用户界面工具箱中,一个可移植的 Wi n d o w抽象部分的实现。例如,这
一抽象部分应该允许用户开发一些在 X Window System和I B M的Presentation Manager(PM)系
统中都可以使用的应用程序。运用继承机制,我们可以定义 Wi n d o w抽象类和它的两个子类
XWindow与PMWindow,由它们分别实现不同系统平台上的 Window界面。但是继承机制有两个不足之处:
1) 扩展 Wi n d o w抽象使之适用于不同种类的窗口或新的系统平台很不方便。假设有
Window的一个子类 I c o n Wi n d o w,它专门将Window抽象用于图标处理。为了使 IconWindow支
持两个系统平台,我们必须实现两个新类 X I c o n Wi n d o w和P M I c o n Wi n d o w,更为糟糕的是,
我们不得不为每一种类型的窗口都定义两个类。而为了支持第三个系统平台我们还必须为每

一种窗口定义一个新的 Window子类,如下图所示

2) 继承机制使得客户代码与平台相关。

     每当客户创建一个窗口时,必须要实例化一个具体的类,这个类有特定的实现部分。例如,创建 

X w i n d o w对象会将 Wi n d o w抽象与 X Wi n d o w
的实现部分绑定起来,这使得客户程序依赖于 X Window的实现部分。这将使得很难将客户代
码移植到其他平台上去。
       客户在创建窗口时应该不涉及到其具体实现部分。仅仅是窗口的实现部分依赖于应用运
行的平台。这样客户代码在创建窗口时就不应涉及到特定的平台。
       B r i d g e模式解决以上问题的方法是,将 Wi n d o w抽象和它的实现部分分别放在独立的类层
次结构中。其中一个类层次结构针对窗口接口( Wi n d o w、I c o n Wi n d o w、Tr a n s i e n t Wi n d o w)
,另外一个独立的类层次结构针对平台相关的窗口实现部分,这个类层次结构的根类为
WindowImp。例如XwindowImp子类提供了一个基于 X Window系统的实现,如下页上图所示。
对Wi n d o w子类的所有操作都是用 Wi n d o w I m p接口中的抽象操作实现的。这就将窗口的抽
象与系统平台相关的实现部分分离开来。因此,我们将 Window与WindowImp之间的关系称之
为桥接,因为它在抽象类与它的实现之间起到了桥梁作用,使它们可以独立地变化。

适用性
      以下一些情况使用 Bridge模式:
• 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为,
在程序运行时刻实现部分应可以被选择或者切换。
• 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时 B r i d g e模式使你
可以对不同的抽象接口和实现部分进行组合,并分别对它们进行扩充。
• 对一个抽象的实现部分的修改应对客户不产生影响,即客户的代码不必重新编译。
• (C + +)你想对客户完全隐藏抽象的实现部分。在 C + +中,类的表示在类接口中是可见的。
• 正如在意图一节的第一个类图中所示的那样,有许多类要生成。这样一种类层次结构说
明你必须将一个对象分解成两个部分。 R u m b a u g h称这种类层次结构为“嵌套的普化”(nested generalizations)。
• 你想在多个对象间共享实现(可能使用引用计数),但同时要求客户并不知道这一点。
一个简单的例子便是 Coplien的String类[Cop92],在这个类中多个对象可以共享同一个字符串表示( StringRep)。

结构

参与者
• Abstraction (Window)
— 定义抽象类的接口。
— 维护一个指向Implementor类型对象的指针。
• RefinedAbstraction (IconWindow)
— 扩充由Abstraction定义的接口。
• Implementor (WindowImp)
— 定义实现类的接口,该接口不一定要与 A b s t r a c t i o n的接口完全一致;事实上这两个
接口可以完全不同。一般来讲, I m p l e m e n t o r接口仅提供基本操作,而 A b s t r a c t i o n则
定义了基于这些基本操作的较高层次的操作。
• ConcreteImplementor (XwindowImp, PMWindowImp)
— 实现Implementor接口并定义它的具体实现。
7. 协作
• Abstraction将client的请求转发给它的 Implementor对象。
8. 效果
Bridge模式有以下一些优点:
1) 分离接口及其实现部分
      一个实现未必不变地绑定在一个接口上。抽象类的实现可以
在运行时刻进行配置,一个对象甚至可以在运行时刻改变它的实现。
将A b s t r a c t i o n与I m p l e m e n t o r分离有助于降低对实现部分编译时刻的依赖性,当改变一个
实现类时,并不需要重新编译 A b s t r a c t i o n类和它的客户程序。为了保证一个类库的不同版本
之间的二进制兼容性,一定要有这个性质。
        另外,接口与实现分离有助于分层,从而产生更好的结构化系统,系统的高层部分仅需
知道Abstraction和Implementor即可。
2) 提高可扩充性 你可以独立地对 Abstraction和Implementor层次结构进行扩充。
3 ) 实现细节对客户透明
       你可以对客户隐藏实现细节,例如共享 I m p l e m e n t o r对象以及相应的引用计数机制(如果有的话)。