目的：
将抽象与抽象方法的实现相分离，使得它们可以独自变化。常用于驱动程序中，使得顶层逻辑不受驱动底层改变的影响，如数据库的变化。
关键词：Bridge, 抽象与实现分离，驱动程序
必要性：从一般抽象类层次结构到Bridge模式
"抽象（abstraction）"指依赖一系列抽象方法的类，通过具体子类的继承，这些抽象方法可以有多种不同的实现。一般的类层次结构如图一。
图一
在上述的类层次结构中，抽象类Manager定义了必要的行为（start和stop），具体类ConcreteManager1和ConcreteManager2根据控制对象的不同各自的实现。如果已有现存的具体实现可以采用Adapter（适配器）模式中的对象适配方式，类层次如图二：
图二
以前的程序通常遵循这样的结构。但是，这样的层次存在明显的不足。例如我们要引入新的控制行为，如设置与机器的交互参数setParam()。根据上述的类层次，我们只能执行如下扩展，如图三所示。
图三
如果要扩展5种Manager，那么就要扩展5个类，即使setParam中包含的代码都相同，因为不同种类的Manager对应于不同种类的机器。
因此我们寻求Bridge（桥接）模式，将抽象与抽象实现相分离，实现两个平面上的自由扩展，类层次如图四。
图四
上述结构中，Driver向Manager提供统一的接口，并由ConcreteDriver来具体实现。对于应用层逻辑的新需求，只需要继承Manager类扩展即可。
应用：驱动程序中的Bridge（桥接）模式
驱动程序包含Adapter和Bridge两种模式。其中，每个驱动程序都是Adapter模式的一个实例，利用其他类的不同接口适配用户要求的接口（位于ConcreteDriver的实现部分）；使用驱动程序的应用层逻辑是Bridge模式的一个实例，将应用程序的开发与驱动开发分离。一个好的例子是JDBC。
设计模式的出发点是什么？就是可扩展性，也就是在不改变原来类结构的基础上引入新的特性。