桥接(Bridge)模式

桥接(Bridge)模式

隶属类别——对象结构型模式

---

1. 意图

将抽象的部分和它的实现部分分离，使他们都可以独立变化。

2. 别名

Handle/Body

3. 动机

当一个抽象可能有多个实现时，通常用继承来协调它们。抽象类定义对该抽象的接口。而具体的子类则用不同方式加以实现。但是此方法有时不够灵活，继承机制将抽象部分与它的实现部分固定在一起，使得难以对抽象部分和实现部分独立地进行修改，扩充和重用。

让我们考虑在一个用户界面工具箱中，一个可移植的Window抽象部分的实现。例如，这一抽象部分应该允许用户开发一些在X Window System和IBM的Presentation Manager(PM)系统中都可以使用的应用程序。运用继承机制，我们可以定义Window抽象类和它的两个子类XWindow 与PMWindow，由它们分别实现不同系统平台的Windows界面，但是继承机制有两个不足之处：

• 1. 扩展Window抽象使之适用于不同种类的窗口或新的系统平台很不方便。假设有Window的一个子类IconWindow，它专门将Window抽象用于图标处理。为了使IconWindows支持两个系统平台，我们必须实现两个新类XIconWindow和PMIconWindow，更为糟糕的是，我们不得不为每一种类型的窗口都定义两个类。而为了支持第三个系统平台我们还必须为每一种窗口定义一个新的Window子类，如下图所示：

• 2. 继承机制使得客户代码与平台相关。每当客户创建一个窗口，必须要实例化一个具体的类，这个类有特定的实现部分。例如，创建XWindow对象会将Window抽象与X Window的实现部分绑定起来，这使得客户程序依赖于X Window的实现部分。这将使得很难将客户代码移植到其他平台上去。

客户在创建窗口时应该不涉及到其具体实现部分。仅仅是窗口的实现部分依赖于应用运行的平台。这样客户代码在创建窗口时就不应涉及到特定的平台。

Bridge模式解决了以上问题的方法是，将Window抽象和它的实现部分分别放在地理的类层结构中。其中一个类层次结构针对窗口接口(Window,IconWindow,TransientWindow),另外一个独立的类层次结构针对平台相关的窗口实现部分，这个类层次结构的根类为WindowsImpl。例如XWindosImp提供一个基于X Window系统的实现，如图所示：

对Window子类的所有操作都是用WindowImp接口中的抽象操作实现的，这就将窗口的抽象与系统的相关实现分离开来(单一责任原则)。因此，我们1将Window与WindowImp之间的关系称为桥接，因为它在抽象类与它的实现之间起到了桥梁作用，这使他们可以独立地变化，通过委托的方式来进行方法调用，这使得调用更加灵活。

4. 适用性

以下一些情况可以使用Bridge模式：

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

5. 结构

6. 参与者

• Abstraction(Window)
  • 定义抽象类的接口
  • 维护一个指向Implementor类型对象的指针
• RefinedAbstraction(IconWindow)
  • 扩充有Abstraction定义的接口
• Implementor(WindowImp)
  • 定义实现类的接口，该接口不一定要与Abstraction的接口完全一致，事实上这两个接口可以完全不同。一般来讲，Implementor接口仅提供基本操作，而Abstraction则定义了基于这些操作的较高层次的操作。
• ConcreteImplementor(XWindowImp,PMWindowImp)
  • 实现Implementor接口并定义它的具体实现

7. 协作

• Abstraction将client的请求转发给它的Implementor对象。

8. 效果

Bridge模式有以下一些优点：

• 1）分离接口及其实现部分 一个实现未必不变地绑定在一个接口上。抽象类的实现可以在运行时刻进行配置，一个对象甚至可以在运行时刻改变它的实现。

  将Abstraction和Implementor分离有助于降低对实现部分编译时刻的依赖性，当改变一个实现类是，并不需要重新编译Abstraction类和它的客户程序。为了保证一个类库的不同版本之间的二进制兼容性，一定要有这个性质。

  另外，接口与实现分离有助于分层，从而产生更好的结构化系统，系统的高层部分仅需知道Abastraction和Implementor即可。

• 2. 提供可扩充性 你可以独立地对Abstraction和Implementor层次结构进行扩充。
• 3. 实现细节对客户透明 你可以对客户隐藏实现细节，例如共享Implementor对象以及共享的引用计数机制(如果有的话)

Bridge模式的缺点：

• 增加了复杂度

9. 实现

使用Bridge模式需要注意以下一些问题：

• 1. 仅有一个Implementor 在仅有一个实现的时候，没有必要创建一个抽象的Implememtor类。这是Bridge模式的退化情况，在Abstraction与Implementor之间有一种一对一的关系。尽管如此，当你希望改变一个类的实现不会影响到已有的客户程序时，模式的分离机制还是非常有用的——也就是说，不必重新编译它们，仅需重新连接即可。

  在Java仅需Implementor引用设置为private。

• 2. 创建正确的Implementor对象 当存在多个Implementor类的时候，你应该用何种方法，在何时何处确定创建一个哪一个Implement类呢？

  如果Abstraction知道所有的ConcreteImplementor类，它就可以在它的构造器中对其中的一个类进行实例化，它可以通过传递给构造器的参数确定实例化哪一个类。例如，如果一个collection类支持多重实现，就可以根据collection的大小决定实例化哪一个类。链表的实现可以用于较小的collection类，而hash表则可用于就较大的collection类。

  另外一个方法是首先选择一个缺省的实现，然而根据需要改变这个实现。例如，如果一个collection的大小超过了一定的阈值时，它将会切换它的实现，使之更适用于表目较多的collection。

  也可以代理给另一个对象，由它一次决定。在Window/WindowImp的例子中，我们可以引入一个factory对象，该对象的唯一职责就是封装系统平台的细节。这个对象知道如何应该为所用的平台创建何种类型的WindowImpl对象；Window仅需向它请求一个WindowImp,而它会返回正确的WindowImp对象。这种方法的优点是Abstraction类不和任何一个Implementor类直接耦合。

• 3. 共享Implementor对象 在Java中如