桥接模式（Bridge Pattern）

概述

在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。

意图

将抽象部分与实现部分分离，使它们都可以独立的变化。[GOF 《设计模式》]

结构图

图1 Bridge模式结构图

生活中的例子

桥接模式将抽象部分与它的实现分离，使它们能够独立地变化。一个普通的开关控制的电灯、电风扇等等，都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀拉链开关，也可以是调光开关。

图2 使用电子开关例子的桥接对象图

桥接模式解说

在创建型模式里面，我曾经提到过抽象与实现，抽象不应该依赖于具体实现细节，实现细节应该依赖于抽象。看下面这幅图：

图3  抽象不应该依赖于实现细节

在这种情况下，如果抽象B稳定，而实现细节b变化，这时用创建型模式来解决没有问题。但是如果抽象B也不稳定，也是变化的，该如何解决？这就要用到Bridge模式了。

以一个日志记录工具这个例子来说明Bridge模式，现在我们要开发一个通用的日志记录工具，它支持数据库记录DatabaseLog和文本文件记录FileLog两种方式，同时它既可以运行在.NET平台，也可以运行在Java平台上。
我们把日志记录方式和不同平台上的实现分别当作两个独立的部分来对待，Log及ImpLog，Log是日志记录方式，ImpLog是日志记录在不同平台的实现的基类，结构图如下：
 

 

实现代码：

 

//ImpLog.h
class ImpLog  
{
public:
    virtual ~ImpLog();

    virtual void WriteLog() = 0;
protected:
    ImpLog();
};

//ImpLog.cpp
#include "stdafx.h"
#include "ImpLog.h"

ImpLog::ImpLog()
{

}

ImpLog::~ImpLog()
{

}

//NImpLog.h
#include "ImpLog.h"

class NImpLog : public ImpLog
{
public:
    NImpLog();
    virtual ~NImpLog();

    void WriteLog();
};

//NImpLog.cpp
#include "stdafx.h"
#include "NImpLog.h"
#include <iostream>

using namespace std;

NImpLog::NImpLog()
{

}

NImpLog::~NImpLog()
{

}

void NImpLog::WriteLog()
{
    cout << "在.NET下写日志" << endl;
}

//JImpLog.h
#include "ImpLog.h"

class JImpLog : public ImpLog
{
public:
    JImpLog();
    virtual ~JImpLog();

    void WriteLog();
};

//JImpLog.cpp
#include "stdafx.h"
#include "JImpLog.h"
#include <iostream>

using namespace std;

JImpLog::JImpLog()
{

}

JImpLog::~JImpLog()
{

}

void JImpLog::WriteLog()
{
    cout << "在Java下写日志" << endl;
}

//Log.h
class ImpLog;
class Log
{
public:
    virtual ~Log();

    virtual void Write() = 0;
protected:
    Log();
};

//Log.cpp
#include "stdafx.h"
#include "Log.h"

Log::Log()
{

}

Log::~Log()
{

}

//DBLog.h
#include "Log.h"

class DBLog : public Log
{
public:
    DBLog();
    DBLog(ImpLog*);
    virtual ~DBLog();

    void Write();
private:
    ImpLog* m_pImpLog;
};

//DBLog.cpp
#include "stdafx.h"
#include "DBLog.h"
#include "ImpLog.h"
#include <iostream>

using namespace std;

DBLog::DBLog()
{
    
}

DBLog::DBLog(ImpLog* pImpLog) : m_pImpLog(pImpLog)
{
    
}

DBLog::~DBLog()
{
    if(m_pImpLog != NULL)
    {
        delete m_pImpLog;
        m_pImpLog = NULL;
    }
}

void DBLog::Write()
{
    cout << "数据库日志：";
    m_pImpLog->WriteLog();
}

//TxtLog.h
#include "Log.h"

class TxtLog : public Log  
{
public:
    TxtLog();
    TxtLog(ImpLog*);
    virtual ~TxtLog();

    void Write();
private:
    ImpLog* m_pImpLog;
};

//TxtLog.cpp
#include "stdafx.h"
#include "TxtLog.h"
#include "ImpLog.h"
#include <iostream>

using namespace std;

TxtLog::TxtLog()
{
    
}

TxtLog::TxtLog(ImpLog* pImpLog) : m_pImpLog(pImpLog)
{
    
}

TxtLog::~TxtLog()
{
    if(m_pImpLog != NULL)
    {
        delete m_pImpLog;
        m_pImpLog = NULL;
    }
}

void TxtLog::Write()
{
    cout << "文本日志：";
    m_pImpLog->WriteLog();
}

//main.cpp
#include "stdafx.h"
#include "Log.h"
#include "DBLog.h"
#include "TxtLog.h"
#include "ImpLog.h"
#include "NImpLog.h"
#include "JImpLog.h"

int main(int argc, char* argv[])
{
    ImpLog* pImp = new NImpLog;
    Log* pLog = new DBLog(pImp);
    pLog->Write();
    pLog = new TxtLog(pImp);
    pLog->Write();

    pImp = new JImpLog;
    pLog = new DBLog(pImp);
    pLog->Write();
    pLog = new TxtLog(pImp);
    pLog->Write();

    return 0;
}

 

最后输出为：
数据库日志：在.NET下写日志
文本日志：在.NET下写日志
数据库日志：在Java下写日志
文本日志：在Java下写日志 

 

 

效果及实现要点

1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。

2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。

3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。

4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。

适用性

在以下的情况下应当使用桥梁模式：

1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。

2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。

3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。

4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

总结

Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。