Bridge
意图
将抽象部分与它的实现部分分离，使它们可以独立地变化。
动机
当一个抽象可能有多个实现时，通常用继承来协调它们。抽象类定义对该抽象的接口，而具体的子类则用不同方式加以实现。但是此方法有时不够灵活。继承机制将抽象部分 与它的实现部分固定在一起，使得难以对抽象部分和实现部分独立的进行修改、扩充和重用。
让我们看个例子：
自工业革命以来，我们有了汽车，轮船，飞机等各种工业革命前想不到的黑科技，我们就来看看交通工具的发展。
现在，需要你对我们的交通工具进行建模，你是这样做的（当然这么做是很合理的）：
- 定义交通工具的抽象类——
Vehicle - 将现有的交通工具作为子类，挂到
Vehicle上去，如Car，Bus等
如下图，非常完美，以后再有新的交通工具，如潜水艇，直接继承自Vehicle就好了
哈哈，直到有一天，人类开始使用可再生能源设计交通工具，而原先的交通工具都是烧石油的，当然这也没关系，我们可以无痛的挂到Vehicle下面，就是不太好看罢了：
不止如此，人们发现新能源来的太慢，而人们已经掌握了核能，而且可以很安全的使用它，又来了一批核动力交通工具，没关系，我们继续挂到Vehicle下面：
就这样工作到你退休，都没有问题，但是人们现在正在研究一种比核能更好的能源，而你的设计，怎么说呢？能够应对变化，但是给人感觉不够灵活，难道每增加一种新动力，就把所有的交通工具都实现一遍吗？
这时候，他们在你的遗嘱上发现了——桥接模式，你临死前突然醒悟，当第一次使用新能源的时候，就应该将设计修改为桥接模式，那么后续的修改都会更简单。
好了，让我们看看平行时空中的另一个你是怎么做的，
当后续在增加核动力的时候，直接加一个新的_power_就好了，多简单。
桥接模式就是这样，它叫抽线与实现解耦，使得对各自的改变不影响对方。
但我不认为桥接模式可以事先应用，因为我们并不知道变化的方向，这里就涉及到了类的演变的维度，类的演变不是单维度的，类可能朝着不同的维度同时演变，但我们事先是不知道的，我们的设计处于对将来变化的考虑，其实都是靠猜的，桥接模式的作用就是当我们猜错了的时候，能够快速的改正回来。这就是我的理解了，可能比较乱。
结构
桥接模式的uml图：
相关模式
Abstract Factory模式可以用来创建和配置一个特定的Bridge模式。
Adapter模式用来帮助无关的类协同工作，它通常在系统设计完成后才会被使用。然而，Bridge模式则是在系统开始时就被使用，它使得抽象接口和实现部分可以独立的进行改变。