Bridge模式
《设计模式》对Bridge模式的意图叙述为：将抽象与实现解耦，使它们都可以独立地变化。（一开始没太懂抽象为啥能和实现分离，后来读完才知道，这里的指A抽象与B实现解耦，而不是指同一个对象）
这里的实现指的是抽象类及其派生类用来实现自己的对象（而不是抽象类的派生类，这些派生类被称为具体类）。
示例研究
1、示例初始描述
编写一个程序，使用两种绘图程序之一绘制矩形（使用两个对点的坐标定义）。已知两种绘图程序DP1和DP2：
| DP1 | DP2 | |
|---|---|---|
| 画线 | draw_a_line(x1,y1,x2,y2) | drawline(x1,x2,y1,y2) |
| 画圆 | draw_a_circle(x,y,r) | drawcircle(x,y,r) |
矩形和绘图程序（DP1和DP2）设计的类图如下：
解决方案：引入抽象类Rectangle,V1Rectangle和V2Rectangle分别使用DP1和DP2引用实现。
2、需求变更
现在需要使用DP1和DP2增加支持另一种形状Circle。
解决方案如下：
但是这个方法带来的新的问题，考虑如下情况：
- Shape类的具体类型有4中
- 如果还有一种绘图程序，那么将产生具体类型6种
- 如果还有一种图形需要绘制，那么将产生具体类型9种
于是爆炸性增长问题出现了。因为这个方案中的抽象与其实现是紧耦合的。每种形状都必须知道自己使用了何种绘图程序。需要有一种方式将抽象上的变化和实现上的变化分开。
Bridge模式
当存在一个抽象有不同实现时，Bridge模式最为适用，它可以是抽象和实现相互独立地进行变化。
首先找到什么在发生变化。上述问题里，变化的是形状的种类和绘图程序的种类。共同概念是“形状”和“绘图程序”。
解决方案如下：
Shape类通过Drawing类具体实现自己的行为。
| Bridge模式 | 关键特征 |
|---|---|
| 意图 | 将一组实现与另一组使用它们的对象分离 |
| 问题 | 一个抽象类的派生类必须使用多个实现，但不能出现类的爆炸性增长 |
| 解决方案 | 为所有实现定义一个接口，供抽象类的所有派生类使用 |
| 参与者与协作者 | AbStraction为要实现的对象定义接口，Implememtor为具体的实现类定义接口。Abstraction的派生类使用Implementor的派生类，但无需知道自己具体使用了哪一个ConcreteImplementor |
| 效果 | 实现与使用的对象解耦，提供了可扩展性，客户无需关注实现问题 |
| 实现 | 1、将实现封装在抽象类中 2、在要实现的抽象类的基类汇总包含一个实现的句柄。注意：在Java中，你可以在实现中使用接口代替抽象类 |
参考《设计模式解析》第二版