桥接模式

设想要绘制一幅图画，蓝天、白云、绿树、小鸟，如果画面尺寸很大，那么用蜡笔绘制就会遇到点麻烦。毕竟细细的蜡笔要涂出一片蓝天，是有些麻烦。如果 有可能，最好有套大号蜡笔，粗粗的蜡笔很快能涂抹完成。至于色彩吗，最好每种颜色来支粗的，除了蓝天还有绿地呢。这样，如果一套12种颜色的蜡笔，我们需 要两套24支，同种颜色的一粗一细。呵呵，画还没画，开始做梦了：要是再有一套中号蜡笔就更好了，这样，不多不少总共36支蜡笔。

 

再看看毛笔这一边，居然如此简陋：一套水彩12色，外加大中小三支毛笔。你可别小瞧这"简陋"的组合，画蓝天用大毛笔，画小鸟用小毛笔，各具特色。

 

呵 呵，您是不是已经看出来了，不错，我今天要说的就是Bridge模式。为了一幅画，我们需要准备36支型号不同的蜡笔，而改用毛笔三支就够了，当然还要搭 配上12种颜料。通过Bridge模式，我们把乘法运算3×12＝36改为了加法运算3＋12＝15，这一改进可不小。那么我们这里蜡笔和毛笔到底有什么 区别呢？

实际上，蜡笔和毛笔的关键一个区别就在于笔和颜色是否能够分离。【GOF95】桥梁模式的用意是"将抽象化 (Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。关键就在于能否脱耦。蜡笔的颜色和蜡笔本身是分不 开的，所以就造成必须使用36支色彩、大小各异的蜡笔来绘制图画。而毛笔与颜料能够很好的脱耦，各自独立变化，便简化了操作。在这里，抽象层面的概念 是："毛笔用颜料作画"，而在实现时，毛笔有大中小三号，颜料有红绿蓝等12种，于是便可出现3×12种组合。每个参与者（毛笔与颜料）都可以在自己的自 由度上随意转换。

蜡笔由于无法将笔与颜色分离，造成笔与颜色两个自由度无法单独变化，使得只有创建36种对象才能完成任务。Bridge 模式将继承关系转换为组合关系，从而降低了系统间的耦合，减少了代码编写量。但这仅仅是Bridge模式带来的众多好处的一部分，更多层面的内容，请参考 《设计模式（16）－Bridge Pattern》。

 

 模式结构

      下图是桥接模式的UML结构图：

 

 

      桥接模式主要包含如下几个角色：

      Abstraction：抽象类。 
      RefinedAbstraction：扩充抽象类。 
      Implementor：实现类接口。 
      ConcreteImplementor：具体实现类 。 

Abstraction ab = new RefinedAbstraction(new ConcreteImplementorA);多用组合，少用继承的完美体现。

模式实现

      模式场景我们就采用哪个画图的。其UML结构图如下：

模式使用场景

       1、如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。

       2、对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。

       3、一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。

模式总结

      1、桥接模式实现了抽象化与实现化的脱耦。他们两个互相独立，不会影响到对方。

      2、对于两个独立变化的维度，使用桥接模式再适合不过了。

      3、对于“具体的抽象类”所做的改变，是不会影响到客户。

桥接模式应该属于结构型模型，因为它用意在于如何更有弹性的组织一个类。当一个类是由多个维度的属性组合而成的时候，如果每个类都进行定义，那么就会类爆炸，不适合类的管理，而且这种设计没有任何弹性可言。当每个维度定义一个接口时，那么就可以弹性的组合各种属性，形成新的类，类的数目减少，复用性高。

抽取变化：对象由不同的变化维度组合而成，因此抽离出来定义。