C++设计模式——Bridge桥接模式

一，桥接模式简介

桥接模式是一种结构型设计模式，用于将抽象与实现分离，这里的"抽象"和"实现"都有可能是接口函数或者类。

桥接模式让抽象与实现之间解耦合，使得开发者可以更关注于实现部分，调用者(Client)可以更关注于抽象部分。

桥接模式可以将一个复杂的类进行拆分为好几个类，开发者可以修改其中任意一个类的实现，而不影响其他类的正常运行，该模式可以降低代码的维护工作量，降低代码风险。

桥接模式的核心就是：抽象化(Abstraction)与实现化(Implementation)

抽象化：忽略一些细节，将具有共同特征的不同实体抽象为同一个对象。

实现化：为抽象化提供具体的逻辑和代码实现。

举个例子：

假设有一堆几何体，这些几何体有形状、颜色等特征，形状有：矩形、圆形，颜色有：红色、蓝色。

为了使用类来描述这些几何体，我们可以将他们抽象为四个子类：红色矩形，蓝色矩形，红色圆形，蓝色圆形。

按照以上方式，如果几何体还包含更多种类的形状和颜色，例如椭圆、绿色，那么这些特征通过排列组合产生的子类将会呈指数级增长。如果此时使用桥接模式，将会大大降低类与类之间的耦合，减少了开发期间的代码量。

对应UML类图：

桥接模式将继承关系改为组合关系，对于以上几何体的描述，我们使用一个类来描述几何体的矩形、圆形等形状，我们使用另一个类来描述几何体的红色、蓝色等颜色，最后将这两个类的实例进行组合。当需要改变类的颜色或形状的实现时，无需修改整个类的实现，只需要修改颜色或形状的实现即可。

对应UML类图：

二，桥接模式的结构

桥接模式主要涉及的类：
**1. 抽象角色类：**是一个类，定义了统一的对外接口，并定义了接口的组成结构，但是不包含接口对应的具体实现。
**2. 具体实现类：**是一个或多个类，该类包含了对抽象角色类的接口的具体代码实现。这些类可以根据需求变化而独立变化，且不会影响到其他类的功能。具体实现类与抽象角色类之间的关联方式采用的是组合而非继承。
**3. 桥接类：**充当了抽象角色类和具体实现类之间的桥梁，负责维护抽象角色类和具体实现类之间的关系，它允许客户端在运行时选择使用哪个具体实现类。
桥接模式的主要组件：
**1.Abstraction：**抽象类，提供统一的抽象接口。内部包含对Implementor类对象的引用。
**2.RefinedAbstraction：**扩充抽象类，有的教程里面称为"ExtendedAbstraction"，Abstraction的子类，扩充Abstraction的抽象接口。
**3.Implementor：**实现类，提供了实现类的接口，这个接口的功能和以上的抽象接口不同。
**4.ConcreteImplementor：**提供了实现类的接口对应的代码逻辑。
桥接模式UML类图：

代码实现：

#include <iostream>

class Implementation {
public:
    virtual ~Implementation() {}
    virtual std::string newOperation() const = 0;
};

class ConcreteImplementationA : public Implementation {
public:
    std::string newOperation() const override {
        return "ConcreteImplementationA: Here's the result on the platform A.\n";
    }
};
class ConcreteImplementationB : public Implementation {
public:
    std::string newOperation() const override {
        return "ConcreteImplementationB: Here's the result on the platform B.\n";
    }
};

class Abstraction {
protected:
    Implementation* implementation_;

public:
    Abstraction(Implementation* implementation) : implementation_(implementation) {
    }

    virtual ~Abstraction() {
    }

    virtual std::string doOperation() const {
        return "Abstraction: Base operation with:\n" +
            this->implementation_->newOperation();
    }
};

class RefinedAbstraction : public Abstraction {
public:
    RefinedAbstraction(Implementation* implementation) : Abstraction(implementation) {
    }
    std::string doOperation() const override {
        return "RefinedAbstraction: Extended operation with:\n" +
            this->implementation_->newOperation();
    }
};

void ClientCode(const Abstraction& abstraction) {
    std::cout << abstraction.doOperation();
}

int main() {
    Implementation* implementation_1 = new ConcreteImplementationA;
    Abstraction* abstraction_1 = new Abstraction(implementation_1);
    ClientCode(*abstraction_1);
    std::cout << std::endl;
    delete implementation_1;
    delete abstraction_1;

    Implementation* implementation_2 = new ConcreteImplementationB;
    Abstraction* abstraction_2 = new RefinedAbstraction(implementation_2);
    ClientCode(*abstraction_2);

    delete implementation_2;
    delete abstraction_2;

    return 0;
}

运行结果：

Abstraction: Base operation with:
ConcreteImplementationA: Here's the result on the platform A.

RefinedAbstraction: Extended operation with:
ConcreteImplementationB: Here's the result on the platform B.

三，桥接模式的应用场景

**系统组件升级：**当需要为现有系统增加新功能或替换已有功能，但又不希望改变原有接口时。

**跨平台应用开发：**使用桥接模式来处理不同操作系统或硬件平台的差异，例如在移动端APP应用中，UI组件同时兼容ios和Android平台。

**第三方插件开发：**使用桥接模式开发出可支持多种第三方服务的组件，例如移动支付api。

**API扩展：**当API的功能需要被扩展，又希望保持原有API的稳定时，使用桥接模式可以隐藏实现细节。

四，桥接模式的优缺点

桥接模式的优点：

分离接口的抽象与实现部分。

替代了继承的实现方式，代码的可复用性更强。

桥接模式可以修改任意一个模块的功能实现而不影响整个系统。

可以向用户隐藏实现细节。

降低了类之间的依赖性。

代码的可维护性很强，可以根据需求灵活地更换实现模块。

桥接模式的缺点：

引入了额外的抽象层，使系统变得更复杂。

会额外增加系统的理解与设计难度。

接口调用增多，带来额外的性能开销。

五，代码实战

代码实战：

生产不同颜色和不同车型的汽车

#include<iostream>
#include<string>

using namespace std;

class IColor
{
public:
    virtual string Color() = 0;
};

class RedColor : public IColor
{
public:
    string Color()
    {
        return "of Red Color";
    }
};

class BlueColor : public IColor
{
public:
    string Color()
    {
        return "of Blue Color";
    }
};

class ICarModel
{
public:
    virtual string WhatIsMyType() = 0;
};

class Model_A : public ICarModel
{
    IColor* _myColor;
public:
    Model_A(IColor *obj) :_myColor(obj){}
    string WhatIsMyType()
    {
        return "I am a Model_A " + _myColor->Color();
    }
};

class Model_B : public ICarModel
{
    IColor* _myColor;
public:
    Model_B(IColor *obj) :_myColor(obj){}
    string WhatIsMyType()
    {
        return "I am a Model_B " + _myColor->Color();;
    }
};

int main()
{
    IColor* red = new RedColor();
    IColor* blue = new BlueColor();

    ICarModel* modelA = new Model_B(red);
    ICarModel* modelB = new Model_A(blue);

    cout << "\n" << modelA->WhatIsMyType();
    cout << "\n" << modelB->WhatIsMyType() << "\n\n";

    delete red;
    delete blue;
    return 0;
}

运行结果：

I am a Model_B of Red Color
I am a Model_A of Blue Color

六，参考阅读

https://refactoring.guru/design-patterns/bridge

https://design-patterns.readthedocs.io/zh-cn/latest/structural_patterns/bridge.html