Bridge

Bridge

动机

• 由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化
• 如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？

模式定义

• 将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。桥接模式具有结构目的并适用于对象，因此它处理对象的组合。

#include <iostream>

class Abstraction
{
public:
    virtual ~Abstraction() {}

    virtual void operation() = 0;
    // ...
};

class Implementor
{
public:
    virtual ~Implementor() {}

    virtual void action() = 0;
    // ...
};

class ConcreteImplementorA : public Implementor
{
public:
    ~ConcreteImplementorA() {}

    void action()
    {
        std::cout << "Concrete Implementor A" << std::endl;
    }
    // ...
};

class ConcreteImplementorB : public Implementor
{
public:
    ~ConcreteImplementorB() {}

    void action()
    {
        std::cout << "Concrete Implementor B" << std::endl;
    }
    // ...
};

class RefinedAbstraction : public Abstraction
{
public:
    ~RefinedAbstraction() {}

    RefinedAbstraction(Implementor *impl) : implementor(impl) {}

    void operation()
    {
        implementor->action();
    }
    // ...

private:
    Implementor *implementor;
};

int main()
{
    Implementor *ia = new ConcreteImplementorA;
    Implementor *ib = new ConcreteImplementorB;

    Abstraction *abstract1 = new RefinedAbstraction(ia);
    abstract1->operation();

    Abstraction *abstract2 = new RefinedAbstraction(ib);
    abstract2->operation();

    delete abstract1;
    delete abstract2;

    delete ia;
    delete ib;

    return 0;
}
/*
Concrete Implementor A
Concrete Implementor B
*/

何时使用

• 希望避免抽象与其实现之间的永久绑定
• 抽象及其实现都应该可以通过子类化来扩展
• 抽象实现的更改不应对客户端产生影响
• 想对客户端完全隐藏抽象的实现

总结

• Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自纬度的变化，即“子类化”它们。
• Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。 Bridge模式是比多继承方案更好的解决方法。
• Bridge模式的应用一般在“两个非常强的变化维度”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。