意图
将抽象部分与它的实现部分分离，使它们都可以独立地变化。 这真的是很抽象的说法。作者的说法是将一个类的功能进行分层，使每层都可以独立的变化。
 动机
当一个抽象可能有多个实现时，通常用继承来协调它们。抽象类定义对该抽象的接口，而具体的子类则用不同方式加以实现。但是此方法有时不够灵活。继承机制将抽象部分与它的实现部分固定在一起，使得难以对抽象部分和实现部分独立地进行修改、扩充和重用。 多态是面向对象的基本手法之一，当类的某个特征需要变化时通常通过继承来实现。设想有一个通讯端口类CommPort，具有打开端口，关闭端口，发送和接收数据等功能。如果需要支持不同的通信方式，就会派生出一个WifiPort类或者BluetoothPort类，如果我们需要加密或者MD5校验功能，就会派生出Base64Port或者Md5Port。这种方式虽然简单易懂，但是存在一个不够灵活的问题。例如生成Md5Port增加校验信息的时候，往往还需要指定一种传输方式。这时类很有可能就变成了Md5WifiPort，编码方式和通信方式需要绑定在一起。没有办法自由组合。如果需要新的功能，就需要构建新类。
让我们考虑在一个用户界面工具箱中，一个可移植的 Window抽象部分的实现。例如，这一抽象部分应该允许用户开发一些在 X Window System和IBM的Presentation Manager(PM)系统中都可以使用的应用程序。运用继承机制，我们可以定义Window抽象类和它的两个子类XWindow与PMWindow，由它们分别实现不同系统平台上的 Window界面。但是继承机制有两个不足之处： 1) 扩展Window抽象使之适用于不同种类的窗口或新的系统平台很不方便。假设有Window的一个子类IconWindow，它专门将Window抽象用于图标处理。为了使IconWindow支持两个系统平台，我们必须实现两个新类XIconWindow和PMIconWindow，更为糟糕的是，我们不得不为每一种类型的窗口都定义两个类。而为了支持第三个系统平台我们还必须为每一种窗口定义一个新的Window子类，如下图所示。     原因很简单，假如存在两个变化的要素，分别存在m和n种变化的可能性，那么就需要m x n个类才能覆盖所有的功能。   2) 继承机制使得客户代码与平台相关。每当客户创建一个窗口时，必须要实例化一个具体的类，这个类有特定的实现部分。例如，创建Xwindow对象会将Win dow抽象与XWindow的实现部分绑定起来，这使得客户程序依赖于XWindow的实现部分。这将使得很难将客户代码移植到其他平台上去。   通讯端口的例子也是一样，由于任何一个类都需要包含完整的通信功能，也就是说无论Base64端口还是Md5端口都必须绑定某种通讯方式，Wifi或者Bluetooth。当我们需要增加新的通讯方式时，必须从已经类中抽出部分代码到新类中。
  客户在创建窗口时应该不涉及到其具体实现部分。仅仅是窗口的实现部分依赖于应用运行的平台。这样客户代码在创建窗口时就不应涉及到特定的平台。
Bridge模式解决以上问题的方法是，将Window抽象和它的实现部分分别放在独立的类层次结构中。其中一个类层次结构针对窗口接口（Window、IconWindow、TransientWindow），另外一个独立的类层次结构针对平台相关的窗口实现部分，这个类层次结构的根类为WindowImp。例如XwindowImp子类提供了一个基于XWindow系统的实现，如下页上图所示。     对Window子类的所有操作都是用WindowImp接口中的抽象操作实现的。这就将窗口的抽象与系统平台相关的实现部分分离开来。因此，我们将WindowWindowImp之间的关系称之为桥接，因为它在抽象类与它的实现之间起到了桥梁作用，使它们可以独立地变化。   本例中希望窗口的实现部分不依赖于平台，所以就将这部分功能独立出来并抽象化。这种做法是面向对象的通行做法，和设计模式无关。叫不叫桥接反而不是那么重要。   作者观点   当存在多个需要变化的特征时，就需要考虑桥接模式了。这时一个很明显的特征就是类名出现了排列组合。   还有一句大白话：想变化哪里，就抽象哪里。哪怕不学设计模式，也应该记住这一句。   注：   本文中蓝 {MOD}粗体文字都引自《设计模式》一书。   觉得本文有帮助？请分享给更多人。 阅读更多更新文章，请扫描下面二维码，关注微信公众号【面向对象思考】