设计模式(15)---->桥接模式
桥梁模式
一、引子
下面的一个例子，有助于理解Bridge模式的设计目的：
设想要绘制一幅图画，蓝天、白云、绿树、小鸟，如果画面尺寸很大，那么用蜡笔绘制就会遇到点麻烦。毕竟细细的蜡笔要涂出一片蓝天，是有些麻烦。如果有可能，最好有套大号蜡笔，粗粗的蜡笔很快能涂抹完成。至于色彩吗，最好每种颜色来支粗的，除了蓝天还有绿地呢。这样，如果一套12种颜色的蜡笔，我们需要两套24支，同种颜色的一粗一细。呵呵，画还没画，开始做梦了：要是再有一套中号蜡笔就更好了，这样，不多不少总共36支蜡笔。
再看看毛笔这一边，居然如此简陋：一套水彩12色，外加大中小三支毛笔。你可别小瞧这"简陋"的组合，画蓝天用大毛笔，画小鸟用小毛笔，各具特色。
呵呵，您是不是已经看出来了，不错，我今天要说的就是Bridge模式。为了一幅画，我们需要准备36支型号不同的蜡笔，而改用毛笔三支就够了，当然还要搭配上12种颜料。通过Bridge模式，我们把乘法运算3×12＝36改为了加法运算3＋12＝15，这一改进可不小。那么我们这里蜡笔和毛笔到底有什么区别呢？
实际上，蜡笔和毛笔的关键一个区别就在于笔和颜色是否能够分离。桥梁模式的用意是"将抽象化 (Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。关键就在于能否脱耦。蜡笔的颜色和蜡笔本身是分不开的，所以就造成必须使用36支色彩、大小各异的蜡笔来绘制图画。而毛笔与颜料能够很好的脱耦，各自独立变化，便简化了操作。在这里，抽象层面的概念是："毛笔用颜料作画"，而在实现时，毛笔有大中小三号，颜料有红绿蓝等12种，于是便可出现3×12种组合。每个参与者（毛笔与颜料）都可以在自己的自由度上随意转换。
蜡笔由于无法将笔与颜色分离，造成笔与颜色两个自由度无法单独变化，使得只有创建36种对象才能完成任务。Bridge模式将继承关系转换为组合关系，从而降低了系统间的耦合，减少了代码编写量。但这仅仅是Bridge模式带来的众多好处的一部分，
二、桥梁模式的定义
"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。这句话有三个关键词，也就是抽象化、实现化和脱耦。
抽象化
存在于多个实体中的共同的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当做同样的实体对待。
实现化
抽象化给出的具体实现，就是实现化。
脱耦
所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。
将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的用意。
三、模式解析
3.1、类图
3.2、包含的角色
可以看出，这个系统含有两个等级结构，也就是：
·由抽象化角色和修正抽象化角色组成的抽象化等级结构。
·由实现化角色和两个具体实现化角色所组成的实现化等级结构。
桥梁模式所涉及的角色有：
·抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
·修正抽象化(RefinedAbstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
·实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
·具体实现化(ConcreteImplementor)角色：这个角色给出实现化角色接口的具体实现。
3.3、一般代码
四、使用场合
-
你不希望在抽象和它的实现部分有一个固定的绑定关系。例如这种情况可能是因为程序在运行时刻部分应用可以被选择或者切换。
-
类的抽象以及它的实现都可以通过生成子类的方法加以扩充。
-
对一个抽象的实现部分的修改应对客户不产生影响，即客户端的代码不必重新编译。
-
你想在多个对象之间共享实现，但是同时要求客户并不知道这一点
五、例子（不同记录方式、不同平台的日志记录工具）
在创建型模式里面，我曾经提到过抽象与实现，抽象不应该依赖于具体实现细节，实现细节应该依赖于抽象。看下面这幅图：
在这种情况下，如果抽象B稳定，而实现细节b变化，这时用创建型模式来解决没有问题。但是如果抽象B也不稳定，也是变化的，该如何解决？这就要用到Bridge模式了。
我们用日志记录工具这个例子来说明Bridge模式。现在我们要开发一个通用的日志记录工具，它支持数据库记录DatabaseLog和文本文件记录FileLog两种方式，同时它既可以运行在.NET平台，也可以运行在Java平台上。
根据我们的设计经验，应该把不同的日志记录方式分别作为单独的对象来对待，并为日志记录类抽象出一个基类Log出来，各种不同的日志记录方式都继承于该基类：
图 Log类结构图
实现代码如下
Log
public interface Log
{
public void write(String log);
}
DatabaseLog
public class DatabaseLog implements Log
{
public void write(String log)
{
// ......Log Database
}
}
TextFileLog
public class TextFileLog implements Log
{
public void write(String log)
{
// ......Log Text File
}
}
另外考虑到不同平台的日志记录，对于操作数据库、写入文本文件所调用的方式可能是不一样的，为此对于不同的日志记录方式，我们需要提供各种不同平台上的实现，对上面的类做进一步的设计得到了下面的结构图：
图
实现代码如下：
JDatabaseLog
public class JDatabaseLog extends DatabaseLog
{
@Override
public void write(String log)
{
//......(Java平台)Log Database
}
}
JTextFileLog
public class JTextFileLog extends TextFileLog
{
@Override
public void write(String log)
{
//......(Java平台)Log TextFile
}
}
NDatabaseLog
public class NDatabaseLog extends DatabaseLog
{
@Override
public void write(String log)
{
//......(.NET平台)Log Database
}
}
NTextFileLog
public class NTextFileLog extends TextFileLog
{
@Override
public void write(String log)
{
//......(.NET平台)Log Text File
}
}
现在的这种设计方案本身是没有任何错误的，假如现在我们要引入一种新的xml文件的记录方式，则上面的类结构图会变成：
如图中蓝色的部分所示，我们新增加了一个继承于Log基类的子类，而没有修改其它的子类，这样也符合了开放-封闭原则。如果我们引入一种新的平台，比如说我们现在开发的日志记录工具还需要支持Borland平台，此时该类结构又变成了：
同样我们没有修改任何的东西，只是增加了两个继承于DatabaseLog和TextFileLog的子类，这也符合了开放-封闭原则。
但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起Log类变化的原因却有两个，即日志记录方式的变化和日志记录平台的变化；其次是重复代码会很多，不同的日志记录方式在不同的平台上也会有一部分的代码是相同的；再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。上面我们分析的变化只是沿着某一个方向，如果变化沿着日志记录方式和不同的运行平台两个方向变化，我们会看到这个类的结构会迅速的变庞大。
现在该是Bridge模式粉墨登场的时候了，我们需要解耦这两个方向的变化，把它们之间的强耦合关系改成弱联系。我们把日志记录方式和不同平台上的实现分别当作两个独立的部分来对待，对于日志记录方式，类结构图仍然是：
图 不同记录方式
现在我们引入另外一个抽象类ImpLog，它是日志记录在不同平台的实现的基类，结构图如下：
图 不同平台
实现代码如下：
ImpLog
public interface ImpLog
{
public void Execute(String msg);
}
JImpLog
public class JImpLog implements ImpLog
{
public void Execute(String msg)
{
// ...... Java平台
}
}
NImpLog
public class NImpLog implements ImpLog
{
public void Execute(String msg)
{
//...... .NET平台
}
}
这时对于日志记录方式和不同的运行平台这两个类都可以独立的变化了，我们要做的工作就是把这两部分之间连接起来。那如何连接呢？在这里，Bridge使用了对象组合的方式，类结构图如下：
图
实现代码如下：
Log
public abstract class Log
{
protected ImpLog implementor;
public void setImplementor(ImpLog implementor) {
this.implementor = implementor;
}
public abstract void write(String log);
}
TextFileLog
public class TextFileLog extends Log
{
@Override
public void write(String log)
{
implementor.Execute(log);
}
}
DatabaseLog
public class DatabaseLog extends Log
{
@Override
public void write(String log)
{
implementor.Execute(log);
}
}
Client
public class Client
{
public static void main(String[] args)
{
//.NET平台下的Database Log
Log dblog = new DatabaseLog();
dblog.setImplementor(new NImpLog()) ;
dblog.write(".net ");
//Java平台下的Text File Log
Log txtlog = new TextFileLog();
txtlog.setImplementor(new JImpLog());
txtlog.write("java");
}
}
原文地址 http://www.programfan.com/blog/article.asp?id=15963
