面向对象设计模式：桥接模式的蜡笔与毛笔应用

第六章　蜡笔与毛笔——桥接模式

6.1　蜡笔与毛笔

时间：12月21日　　地点：大B房间　　人物：大B，小A

大B：“师弟，你小的时候玩过蜡笔画画吗？”

小A：“有啊。小时候经常都有玩哩。怎么啦？”

大B：“记得那红红绿绿的蜡笔一大盒特别漂亮。”

小A：“嗯。特漂亮！”

大B：“我们那时经常用蜡笔根据想象描绘出格式图样。”

小A：“对啊！特有成就感。还可以用毛笔画国画哩！”

大B：“就是！毛笔下的国画更是工笔写意，各展风采。”

小A：“是啊！小时候觉得特好玩。”

大B：“嘿嘿！对啊！那今天我们就从蜡笔与毛笔说起吧。”

小A：“好啊。”

大B：“设想要绘制一幅图画，蓝天、白云、绿树、小鸟，如果画面尺寸很大，那么用蜡笔绘制就会遇到点麻烦。毕竟细细的蜡笔要涂出一片蓝天，是有些麻烦。如果有可能，最好有套大号蜡笔，粗粗的蜡笔很快能涂抹完成。至于色彩吗，最好每种颜色来支粗的，除了蓝天还有绿地呢。”

小A：“那得要好多蜡笔哩！”

大B：“是啊！这样，如果一套12种颜色的蜡笔，我们需要两套24支，同种颜色的一粗一细。”

小A：“呵呵，画还没画，开始做梦了：要是再有一套中号蜡笔就更好了，这样，不多不少总共36支蜡笔。”

如图6-1蜡笔所示

图6-1　蜡笔

大B：“那当然好。再看看毛笔这一边，居然如此简陋：一套水彩12色，外加大中小三支毛笔。你可别小瞧这‘简陋’的组合，画蓝天用大毛笔，画小鸟用小毛笔，各具特色。如图6-2毛笔所示”

图6-2　毛笔

小A：“呵呵！我好像已经看出你今天想要说的模式了。”

大B：“不错！我今天要说的就是Bridge模式。”

小A：“还真被我看出来了哩！”(www.xing528.com)

大B：“为了一幅画，我们需要准备36支型号不同的蜡笔，而改用毛笔三支就够了，当然还要搭配上12种颜料。通过Bridge模式，我们把乘法运算3×12＝36改为了加法运算3＋12＝15，这一改进可不小。”

小A：“那么我们这里蜡笔和毛笔到底有什么区别呢？”

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

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

小A：“那用代码怎么去表示啊？”

大B：“我写给你看一下，你应该就可以明白了。”

本文代码附于此处：

6.2　桥接模式

大B：“聊了那么多，现在你来说说什么是桥接模式吧！”

小A：“桥接器模式（BridgePattern）又称为桥梁模式，它主要用意是为了实现抽象部分与实现部分脱耦，使它们各自可以独立地变化。”

大B：“在开发过程中大家通常会遇到一个对象有两个变化的维度，而且这两个维度变化地非常巨烈，这种变化导致了纵横交错的结果，使对象的设计变得困难，并且在对象数量上和可扩展性上都带来了很大的麻烦。此时我们应当把这两个变化比较巨烈的维度拆离，然后用组合的方式把它们结合在一起。这就是桥接器模式的思想。”

下面是它的结构图，如图6-3所示

图6-3　Bridge模式结构图

小A：“桥接模式的主要特点有哪些啊？”

大B：“1、分离接口及其实现部分，这里实现了Abstraction和Implementor的分离，有助于降低对实现部分的依赖性，从而产生更好的结构化系统。2、提高了可扩充性，可以独立的对Abstraction和Implementor层次结构进行扩充。”

6.3　与适配器有什么不同

小A：“很多时候经常容易把桥接模式和适配器模式弄混。那什么时候用桥接，什么时候用适配器呢?有哪些共同点，又有哪些不同点哩？”

大B：“共同点：桥接和适配器都是让两个东西配合工作不同点：出发点不同。适配器：改变已有的两个接口，让他们相容。 桥接模式：分离抽象化和实现，使两者的接口可以不同，目的是分离。所以说，如果你拿到两个已有模块，想让他们同时工作，那么你使用的适配器。如果你还什么都没有，但是想分开实现，那么桥接是一个选择。桥接是先有桥，才有两端的东西，适配是先有两边的东西，才有适配器，桥接是在桥好了之后，两边的东西还可以变化。例如游戏手柄,就象个桥，它把你的任何操作转化成指令。虽然，你可以任何操作组合，但是你的操作脱不开上下左右，a，b，选择，确定。”

小A：“为什么啊？”

大B：“JRE本身就是一个就是一个很好的桥，先写好在linux上执行的JRE，再写好可以在windows下执行的JRE，这样无论什么样的Java程序，只要配和相应的Jre就能在Linux或者Windows上运行。两个Jre并没有限定你写什么样的程序，但要求你必须用Java来写。”

6.4　适用情况

小A：“师兄，桥梁模式适应在什么时候使用？”

大B：“在以下的情况下应当使用桥梁模式：1、如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。2、设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。3、一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。桥梁模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。”