Bridge模式（桥接模式 结构型）

Bridge是设计模式中比较复杂和难以理解的模式之一，即使用组合的方式将抽象和实现彻底地解耦，这样的好处是抽象和实现可以分别独立地变化，系统的耦合性也得到了很好的降低。

这句话太精简，以至于我很难知道它在说什么……

我觉得这么说更恰当，bridge使用组合的方式，使（抽象A类）和（A类的组成部分抽象B类）的实例化彻底地解耦。这样说我觉得是最贴切的。

举个栗子。

我想要创作一个笔类，那么做为笔它要可以画出颜色，不同的笔可以有不同的颜色，所以我将笔作为基类，画颜色作为它的一个虚函数（可被继承）。结构如下图。

之后我们可以创建出红笔、蓝笔、黑笔，都继承自Pen类，如下图。

这样一看好似没什么问题，很多人都会这么去创作这么个Pen继承体系。我们接着往下走。

有人要买我的Pen体系了，但他要求Pen类要细分为大、中、小三种类型，以满足市场需要。需求改了，怎么办？原先我没预留要创造大、中、小等类型的笔的接口啊！如果我改动了Pen类，增加了纯虚函数，那么对原先的RedPen、BluePen等势必会造成影响。为了改动不太大，我决定为RedPen、BluePen、Black等创建继承体系，即：

就这样，我创建出了大中小、颜色可以为红蓝黑的笔了。如果以后Pen还要增加什么特性，那么类的个数会呈现指数性的增长了，继承深度会加深，类会爆炸。

 

有什么办法能避免这样的事情发生呢？我们可以这么做：用组合替代继承。在Pen类中，drow()是作为虚函数存在的，任何继承了Pen类的子类都要去重载实现这个函数。我们可以换种思路：在类Pen中增加成员Color抽象类，然后让drow()作为普通函数存在，在函数中调用 color->drow()。如下图：

那么新增颜色就会变成这样：

注意到没有，Pen类和Red、Blue、Black的关系是如此得薄弱，完全是外界关联起来的，耦合度非常低，当Pen类发生改变时，即使发生继承，对Color这个继承树的影响基本是没有的，非常符合开源闭合原则，也就是我上面说的抽象A类与A类的成员抽象B类的实例化实现彻底地解耦。这就是bridge模式的实现。

若此时客户要求我为Pen类增加大中小三种类型，我可以有两种选择，一是用继承；二是继续用bridge模式。为了实现彻底地解耦，我再次选择bridge模式，我在Pen类中增加抽象Size类。

模型十分精简，且耦合性极低，类的继承深度减少、数目急剧减少。这就是bridge模式带来的好处。

Bridge模式使用组合的方式将抽象和实现彻底地解耦，这样的好处是抽象和实现可以分别独立地变化，系统的耦合性也得到了很好的降低。