深入浅出桥梁模式

一、引子

桥梁（bright）模式是我介绍的23种模式中的最后一个结构模式。它是一个功能非常强大而且适用于多种情况的模式。

 

二、定义与结构

GOF在《设计模式》中给桥梁模式的定义为：将抽象部分与它的实现部分分离，使它们都可以独立地变化。这里的抽象部分和实现部分不是我们通常认为的父类与子类、接口与实现类的关系，而是组合关系。也就是说，实现部分是被抽象部分调用，以用来完成（实现）抽象部分的功能。

在《Thinking in Patterns with Java》一书中，作者将抽象部分叫做“front-end”（权且翻译为“前端”），而实现部分叫做“back-end”（后端）。这种叫法要比抽象实现什么的好理解多了。

桥梁模式由如下四种角色组成：

1)        抽象（Abstraction）角色：它定义了抽象类的接口而且维护着一个指向实现（Implementor）角色的引用。

2)        精确抽象（RefinedAbstraction）角色：实现并扩充由抽象角色定义的接口。

3)        实现（Implementor）角色：给出了实现类的接口，这里的接口与抽象角色中的接口可以不一致。

4)        具体实现（ConcreteImplementor）角色：给出了实现角色定义接口的具体实现。

它

再放上个类图就更清晰了：

       可是这样的结构能够给我们带来什么呢？？

       系统设计中，总是充满了各种变数，这是防不慎防的。比如客户代表可能要求修改某个需求，增加某种功能等等。面对这样那样的变动，你只能去不停的修改设计和代码，并且要开始新的一轮测试……。

那采取什么样的方式可以较好的解决变化带给系统的影响？你可以分析变化的种类，将不变的框架使用抽象类定义出来，然后再将变化的内容使用具体的子类来分别实现。这样面向客户的只是一个抽象类，这种方式可以较好的避免为抽象类中现有接口添加新的实现所带来的影响，缩小了变化带来的影响。但是这可能会造成子类数量的爆炸，并且在某些时候不是很灵活。

       但是当你各个子类的行为经常发生变化，或者有一定的重复和组合关系时，我们不妨将这些行为提取出来，也采用接口的方式提供出来，然后以组合的方式将服务提供给原来的子类。这样就达到了前端和被使用的后端独立的变化，而且还达到了后端的重用。

       其实这就是桥梁模式的诞生。

三、实例

我现在唯一知道的使用桥梁模式的应用就是java AWT框架。使用过java AWT的人都知道，在不同系统下开发的软件界面都带有不同系统独有的风格。而在使用AWT的API的时候根本就没有对不同系统的区分，你也根本就不需要去关心这一点。AWT中正是使用桥梁模式来做到这一点的。

不过我对AWT的代码不熟悉，所以也没有办法在这里讲解一下。下面只能举一个常见的教学代码了：（

以下代码来自《Thinking in Patterns with Java》：

//抽象部分（前端）的抽象角色

class Abstraction {

      //维护着一个指向实现（Implementor）角色的引用     

      private Implementation implementation;

      public Abstraction(Implementation imp) {

             implementation = imp;

      }

      // 下面定义了前端（抽象部分）应该有的接口

      public void service1() {

             //使用了后端（实现部分）已有的接口

             //组合实现功能

             implementation.facility1();

             implementation.facility2();

      }

      public void service2() {

             implementation.facility2();

             implementation.facility3();

      }

      public void service3() {

             implementation.facility1();

             implementation.facility2();

             implementation.facility4();

      }

      // For use by subclasses:

      protected Implementation getImplementation() {

             return implementation;

      }

}

 

//抽象部分（前端）的精确抽象角色

class ClientService1 extends Abstraction {

      public ClientService1(Implementation imp) { super(imp); }

       //使用抽象角色提供的方法组合起来完成某项功能

       //这就是为什么叫精确抽象角色（修正抽象角色）

      public void serviceA() {

             service1();

             service2();

      }

       public void serviceB() {

             service3();

      }

}

 

//另一个精确抽象角色，和上面一样的被我省略了

class ClientService2 extends Abstraction {

 。。。。

       //这里是直接通过实现部分的方法来实现一定的功能

      public void serviceE() {

             getImplementation().facility3();

       }

}

 

//实现部分（后端）的实现角色

interface Implementation {

  //这个接口只是定义了一定的接口

      void facility1();

      void facility2();

      void facility3();

       void facility4();

}

 

//具体实现角色就是要将实现角色提供的接口实现

//并完成一定的功能

//这里省略了

class Implementation1 implements Implementation {

  。。。

 

在上面的程序中还体现出一点特色：就是不仅实现部分和抽象部分所提供的接口可以完全不一样；而且实现部分内部、抽象部分内部的接口也完全可以不一样。但是实现部分要提供类似的功能才行。

 

四、使用环境与优势

由上面我们分析得来的桥梁模式，可以看出来桥梁模式应该适用于以下环境：

1)        当你的系统中有多个地方要使用到类似的行为，或者是多个类似行为的组合时，可以考虑使用桥梁模式来提高重用，并减少因为行为的差异而产生的子类。

2)        系统中某个类的行为可能会有几种不同的变化趋势，为了有效的将变化封装，可以考虑将类的行为抽取出来。

3)        当然上面的情况也可以是这样，行为可能要被不同相似类使用，也可以考虑使用桥梁模式来实现。

       桥梁模式使用了低耦合性的组合代替继承，使得它具备了不少好处：

1)        将可能变化的部分单独封装起来，使得变化产生的影响最小，不用编译不必要的第代码。

2)        抽象部分和实现部分可以单独的变动，并且每一部分的扩充都不会破坏桥梁模式搭起来架子。

3)        对于客户程序来说，你的实现细节是透明的。

Bruce Eckel在《Thinking in patterns with Java》中提到，可以把桥梁模式当作帮助你编码前端和后端独立变化的框架。

 

五、扩展

在《设计模式》一书中提到了使用抽象工厂模式来创建和配置一个桥梁模式。在上面的例子中也使用到了工厂方法模式来得到具体的实现部分。

 

六、总结

以上写出了我对桥梁模式的理解，如有不对之处，还请指正！