C++设计模式实现--桥模式

一、概述：
        在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化。那么为了应对这种“多维度的变化”（即两个以上变化的原因）的系统，可采用Bridge模式来进行设计，使系统中类的个数更少，且系统扩展更为方便。桥接模式将继承关系转换为关联关系，从而降低了类与类之间的耦合，减少了代码编写量。
二、UML图：
       
三、优缺点：
        优点：1)将可能变化的部分单独封装起来，使得变化产生的影响最小，不用编译不必要的第代码。
                    2)抽象部分和实现部分可以单独的变动，并且每一部分的扩充都不会破坏桥梁模式搭起来架子。
                    3)实现细节对客户透明
        缺点：1)结构比较复杂。
                    2)抽象类的修改影响到子类。

四、应用场景：

       模拟毛笔：
       现需要提供大中小3种型号的画笔，能够绘制5种不同颜色，如果使用蜡笔，我们需要准备3*5=15支蜡笔，也就是说必须准备15个具体的蜡笔类。而如果使用毛笔的话，只需要3种型号的毛笔，外加5个颜料盒，用3+5=8个类就可以实现15支蜡笔的功能。
       实际上，蜡笔和毛笔的关键一个区别就在于笔和颜色是否能够分离。即将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。关键就在于能否脱耦。蜡笔的颜色和蜡笔本身是分不开的，所以就造成必须使用15支色彩、大小各异的蜡笔来绘制图画。而毛笔与颜料能够很好的脱耦，各自独立变化，便简化了操作。在这里，抽象层面的概念是："毛笔用颜料作画"，而在实现时，毛笔有大中小三号，颜料有红绿蓝黑白等5种，于是便可出现3×5种组合。每个参与者（毛笔与颜料）都可以在自己的自由度上随意转换。
       蜡笔由于无法将笔与颜色分离，造成笔与颜色两个自由度无法单独变化，使得只有创建15种对象才能完成任务。

       Bridge模式将继承关系转换为组合关系，从而降低了系统间的耦合，减少了代码编写量。

五、代码实现：

#include <QDebug>
#define TRACE qDebug

//操作系统
class IOS
{
public:
    IOS(){}
    virtual ~IOS(){}

    virtual void Run()=0;
};

class CWindows : public IOS
{
public:
    CWindows(){}
    virtual ~CWindows(){}

    virtual void Run()
    {
        TRACE("[Window OS]!\n");
    }
};

class CLinux : public IOS
{
public:
    CLinux(){}
    virtual ~CLinux(){}

    virtual void Run()
    {
        TRACE("[Linux OS]!\n");
    }
};

//电脑品牌
class ICompute
{
public:
    ICompute(){}
    virtual ~ICompute(){}

    virtual void Install(IOS* pOS)=0;
};

class CIBM : public ICompute
{
public:
    CIBM(){}
    virtual ~CIBM(){}

    virtual void Install(IOS* pOS)
    {
        TRACE("IBM compute install ");
        pOS->Run();
    }
};

class CHP : public ICompute
{
public:
    CHP(){}
    virtual ~CHP(){}

    virtual void Install(IOS* pOS)
    {
        TRACE("HP compute install ");
        pOS->Run();
    }
};

int main()
{
    IOS* pW = new CWindows();
    IOS* pL = new CLinux();

    ICompute* pIBM = new CIBM();
    pIBM->Install(pW);
    pIBM->Install(pL);

    return 0;
}

六、综述：

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