桥接模式实战拆解：用 C++ 解耦抽象与实现，彻底告别类爆炸！

class 卑微码农:
    def __init__(self):
        self.技能 = ['能读懂十年前祖传代码', '擅长用Ctrl+C/V搭建世界', '信奉"能跑就别动"的玄学']
        self.发量 = 100  # 初始发量
        self.咖啡因耐受度 = '极限'
        
    def 修Bug(self, bug):
        try:
            # 试图用玄学解决问题
            if bug.严重程度 == '离谱':
                print("这一定是环境问题！")
            else:
                print("让我看看是谁又没写注释...哦，是我自己。")
        except Exception as e:
            # 如果try块都救不了，那就...
            print("重启一下试试？")
            self.发量 -= 1  # 每解决一个bug，头发-1
 
 
# 实例化一个我
我 = 卑微码农()

前言

开篇先给大家看一个真实开发场景：假设你要开发一个图形绘制工具，需要支持两种形状（圆形、方形）和三种颜色（红色、蓝色、绿色）。如果用传统方式设计，你需要创建 红色圆形「红色方形」「蓝色圆形」「蓝色方形」「绿色圆形」「绿色方形」6 个类；要是后续新增三角形和黄色，就得再加 2 个新类，新增 10 种形状和 8 种颜色的话，需要创建 80 个类 —— 这就是典型的 “类爆炸” 问题，代码冗余且难以维护。

而用桥接模式设计，只需创建 2 个形状类、3 个颜色类，再通过一个 “桥” 将两者关联，新增形状或颜色时只需新增对应类，无需修改原有代码。这种 “抽象与实现分离，各自独立扩展” 的设计思路，正是桥接模式的核心价值。

本文会结合 3 个递进式 C++ 实战示例（从基础到进阶），从痛点分析、原理拆解、代码实现到实际应用，全方位讲解桥接模式。无论你是刚学设计模式的新手，还是想在项目中落地设计模式的开发者，都能看懂、会用，干货满满，建议收藏慢慢看。

一、先搞懂：为什么需要桥接模式？（从实际痛点出发）

在讲桥接模式的定义之前，我们先通过两个真实开发场景，理解它要解决的核心问题 ——解耦 “抽象维度” 和 “实现维度”，避免类爆炸，支持独立扩展。

场景 1：图形绘制工具的 “类爆炸” 困境

如开篇所述，图形绘制工具包含两个独立变化的维度：

抽象维度：形状（圆形、方形、三角形...）
实现维度：颜色（红色、蓝色、绿色...）

传统设计思路是 “将两个维度的组合直接定义为类”，本质是 “继承复用”—— 每个具体图形都继承自形状基类，同时在类内部实现颜色逻辑。这种设计的问题很明显：

类数量呈 “抽象维度数量 × 实现维度数量” 增长，扩展困难；
形状和颜色逻辑耦合在一起，修改颜色逻辑需要改动所有关联的形状类；
代码冗余严重，不同形状的颜色绘制逻辑重复。

场景 2：支付系统的扩展难题

假设你要开发一个支付系统，需要支持两种支付方式（微信支付、支付宝支付）和两种支付场景（APP 支付、H5 支付）。传统设计同样会出现 “类爆炸”：微信 APP 支付、微信 H5 支付、支付宝 APP 支付、支付宝 H5 支付 4 个类。

如果后续新增 “银联支付” 和 “小程序支付”，又要新增 2 个类；要是再新增 “支付回调逻辑”“支付退款逻辑”，类数量会指数级增长，代码维护成本极高。

核心痛点总结

这两个场景的共性问题的是 “存在多个独立变化的维度”，而传统设计将这些维度耦合在同一个类层级中，导致：

类数量爆炸，扩展困难；
代码冗余，修改一处需要改动多个类；
耦合度高，不符合 “开闭原则”（对扩展开放，对修改关闭）。

而桥接模式的出现，正是为了解决 “多维度独立变化” 的设计难题 —— 它通过 “组合替代继承” 的方式，将不同维度拆分为独立的类层级，再通过一个 “桥” 将它们关联起来，实现维度的独立扩展。

二、桥接模式核心原理：3 个角色 + 1 个核心思想

1. 核心思想

桥接模式（Bridge Pattern）的官方定义是：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

通俗理解：把两个（或多个）独立变化的维度，拆分成两个（或多个）独立的类层级，然后通过 “组合” 的方式将这些层级连接起来（这个组合关系就是 “桥”），从而支持每个维度的独立扩展。

2. 3 个核心角色

桥接模式的结构很清晰，主要包含 3 个角色，我们结合 “图形绘制” 场景来理解：

（1）抽象化角色（Abstraction）

定义抽象维度的核心接口，同时持有 “实现化角色” 的引用（这就是 “桥”）。
示例：Shape（形状）类，定义图形的绘制接口（draw()），同时持有Color（颜色）类的引用。

（2）扩展抽象化角色（Refined Abstraction）

继承自抽象化角色，对抽象接口进行具体实现或扩展。
示例：Circle（圆形）、Square（方形）类，继承自Shape，实现各自的绘制逻辑（如圆形绘制轮廓、方形绘制边框）。

（3）实现化角色（Implementor）

定义实现维度的核心接口，提供具体实现的方法，不依赖于抽象化角色。
示例：Color（颜色）类，定义颜色填充接口（fill()）。

（4）具体实现化角色（Concrete Implementor）

继承自实现化角色，对实现接口进行具体实现。
示例：Red（红色）、Blue（蓝色）、Green（绿色）类，继承自Color，实现各自的颜色填充逻辑。

3. 结构示意图（图形绘制场景）

抽象化角色（Shape）
    ↑ 继承
扩展抽象化角色（Circle、Square）
    ↓ 持有（桥）
实现化角色（Color）
    ↑ 继承
具体实现化角色（Red、Blue、Green）

通过这个结构，形状和颜色两个维度完全分离：

新增形状（如三角形）：只需新增Triangle类继承Shape，无需修改颜色相关代码；
新增颜色（如黄色）：只需新增Yellow类继承Color，无需修改形状相关代码；
符合 “开闭原则”，扩展灵活，无类爆炸问题。

三、C++ 实战示例 1：基础版图形绘制工具（入门必看）

我们先通过最基础的图形绘制场景，实现桥接模式的核心逻辑 —— 将 “形状” 和 “颜色” 两个维度分离，支持独立扩展。

1. 实现步骤拆解

定义实现化角色（Color）：提供颜色填充接口；
实现具体实现化角色（Red、Blue、Green）：各自实现颜色填充逻辑；
定义抽象化角色（Shape）：持有Color引用，定义绘制接口；
实现扩展抽象化角色（Circle、Square）：实现各自的绘制逻辑，调用颜色填充接口；
客户端调用：创建具体颜色和形状对象，通过形状对象调用绘制方法。

2. 完整 C++ 代码（可直接运行）

#include <iostream>
#include <string>
using namespace std;

// --------------- 实现化角色（Color）---------------
// 颜色接口（实现化角色）：定义颜色填充的核心方法
class Color {
public:
    virtual ~Color() {} // 虚析构函数，确保子类正确析构
    // 颜色填充方法：返回填充的颜色描述
    virtual string fill() const = 0;
};

// 具体实现化角色：红色
class Red : public Color {
public:
    string fill() const override {
        return "红色";
    }
};

// 具体实现化角色：蓝色
class Blue : public Color {
public:
    string fill() const override {
        return "蓝色";
    }
};

// 具体实现化角色：绿色
class Green : public Color {
public:
    string fill() const override {
        return "绿色";
    }
};

// --------------- 抽象化角色（Shape）---------------
// 形状接口（抽象化角色）：定义图形绘制的核心方法，持有Color引用（桥）
class Shape {
protected:
    Color* color_; // 持有实现化角色的引用，这是"桥"的核心
public:
    // 构造函数：传入颜色对象，建立桥接关系
    Shape(Color* color) : color_(color) {}
    virtual ~Shape() {
        // 此处不负责释放color_，避免重复释放，由客户端管理生命周期
    }
    // 绘制方法：抽象接口，由子类实现
    virtual void draw() const = 0;
};

// 扩展抽象化角色：圆形
class Circle : public Shape {
public:
    // 继承Shape的构造函数
    using Shape::Shape;

    void draw() const override {
        cout << "绘制一个" << color_->fill() << "的圆形" << endl;
    }
};

// 扩展抽象化角色：方形
class Square : public Shape {
public:
    using Shape::Shape;

    void draw() const override {
        cout << "绘制一个" << color_->fill() << "的方形" << endl;
    }
};

// --------------- 客户端调用 ---------------
int main() {
    // 1. 创建具体颜色对象（实现化角色实例）
    Color* red = new Red();
    Color* blue = new Blue();
    Color* green = new Green();

    // 2. 创建具体形状对象（扩展抽象化角色实例），通过构造函数建立桥接
    Shape* redCircle = new Circle(red);
    Shape* blueSquare = new Square(blue);
    Shape* greenCircle = new Circle(green);

    // 3. 调用绘制方法
    redCircle->draw();    // 输出：绘制一个红色的圆形
    blueSquare->draw();   // 输出：绘制一个蓝色的方形
    greenCircle->draw();  // 输出：绘制一个绿色的圆形

    // 4. 释放资源（客户端负责管理对象生命周期）
    delete redCircle;
    delete blueSquare;
    delete greenCircle;
    delete red;
    delete blue;
    delete green;

    return 0;
}

3. 代码解析与运行效果

运行效果：程序会输出三个绘制结果，分别对应不同形状和颜色的组合；
核心亮点：形状和颜色完全分离，新增形状（如三角形）只需新增Triangle类继承Shape，新增颜色（如黄色）只需新增Yellow类继承Color，无需修改原有代码；
桥接关系：Shape类持有Color指针，通过构造函数传入具体颜色对象，这种 “组合” 关系就是 “桥”，实现了抽象维度和实现维度的解耦。

4. 传统设计 vs 桥接模式对比

设计方式	类数量（2 形状 + 3 颜色）	新增 1 个形状	新增 1 个颜色	耦合度
传统设计	6 个（红圆、蓝圆、绿圆、红方、蓝方、绿方）	+3 个（新形状 + 3 颜色）	+2 个（3 形状 + 新颜色）	高
桥接模式	5 个（2 形状 + 3 颜色）	+1 个（仅新形状）	+1 个（仅新颜色）	低

从表格可以明显看出，桥接模式在扩展时的优势 —— 类数量线性增长，而非指数级增长，极大降低了维护成本。

四、C++ 实战示例 2：进阶版支付系统（多维度扩展）

基础示例讲解了两个维度的桥接，接下来我们实现一个更贴近实际开发的支付系统，包含三个维度：

抽象维度 1：支付方式（微信支付、支付宝支付、银联支付）；
抽象维度 2：支付场景（APP 支付、H5 支付、小程序支付）；
实现维度：支付渠道（正式环境、测试环境）。

这个场景更复杂，但核心思路不变 —— 将每个独立变化的维度拆分为独立类层级，通过多重桥接关联。

1. 角色定义

实现化角色：PayChannel（支付渠道），提供支付渠道的核心接口；
具体实现化角色：FormalChannel（正式环境）、TestChannel（测试环境）；
抽象化角色 1：PayMethod（支付方式），持有PayChannel引用，定义支付接口；
扩展抽象化角色 1：WeChatPay（微信支付）、Alipay（支付宝支付）、UnionPay（银联支付）；
抽象化角色 2：PayScene（支付场景），持有PayMethod引用，扩展支付场景逻辑；
扩展抽象化角色 2：AppPay（APP 支付）、H5Pay（H5 支付）、MiniProgramPay（小程序支付）。

2. 完整 C++ 代码

#include <iostream>
#include <string>
#include <ctime>
using namespace std;

// --------------- 实现化角色：支付渠道（PayChannel）---------------
// 支付渠道接口：定义支付渠道的核心方法（如发起支付、获取渠道信息）
class PayChannel {
public:
    virtual ~PayChannel() {}
    // 获取渠道名称
    virtual string getChannelName() const = 0;
    // 发起支付（内部逻辑，如调用第三方接口）
    virtual bool doPay(double amount) const = 0;
};

// 具体实现化角色：正式环境渠道
class FormalChannel : public PayChannel {
public:
    string getChannelName() const override {
        return "正式环境";
    }

    bool doPay(double amount) const override {
        // 模拟正式环境支付逻辑：调用第三方支付接口
        cout << "[正式环境] 发起支付请求，金额：" << amount << "元" << endl;
        // 模拟支付成功（实际开发中需根据接口返回判断）
        return true;
    }
};

// 具体实现化角色：测试环境渠道
class TestChannel : public PayChannel {
public:
    string getChannelName() const override {
        return "测试环境";
    }

    bool doPay(double amount) const override {
        // 模拟测试环境支付逻辑：仅打印日志，不调用真实接口
        cout << "[测试环境] 模拟支付，金额：" << amount << "元（无真实扣款）" << endl;
        return true;
    }
};

// --------------- 抽象化角色1：支付方式（PayMethod）---------------
// 支付方式接口：持有支付渠道引用，定义支付核心接口
class PayMethod {
protected:
    PayChannel* channel_; // 桥接：关联支付渠道
public:
    PayMethod(PayChannel* channel) : channel_(channel) {}
    virtual ~PayMethod() {}
    // 获取支付方式名称
    virtual string getMethodName() const = 0;
    // 支付接口（对外暴露）
    virtual bool pay(double amount) const = 0;
};

// 扩展抽象化角色1：微信支付
class WeChatPay : public PayMethod {
public:
    using PayMethod::PayMethod;

    string getMethodName() const override {
        return "微信支付";
    }

    bool pay(double amount) const override {
        cout << "=== " << channel_->getChannelName() << "-" << getMethodName() << " ===" << endl;
        // 调用支付渠道的支付方法
        bool result = channel_->doPay(amount);
        if (result) {
            cout << getMethodName() << "支付成功！" << endl;
        } else {
            cout << getMethodName() << "支付失败！" << endl;
        }
        return result;
    }
};

// 扩展抽象化角色1：支付宝支付
class Alipay : public PayMethod {
public:
    using PayMethod::PayMethod;

    string getMethodName() const override {
        return "支付宝支付";
    }

    bool pay(double amount) const override {
        cout << "=== " << channel_->getChannelName() << "-" << getMethodName() << " ===" << endl;
        bool result = channel_->doPay(amount);
        if (result) {
            cout << getMethodName() << "支付成功！" << endl;
        } else {
            cout << getMethodName() << "支付失败！" << endl;
        }
        return result;
    }
};

// 扩展抽象化角色1：银联支付
class UnionPay : public PayMethod {
public:
    using PayMethod::PayMethod;

    string getMethodName() const override {
        return "银联支付";
    }

    bool pay(double amount) const override {
        cout << "=== " << channel_->getChannelName() << "-" << getMethodName() << " ===" << endl;
        bool result = channel_->doPay(amount);
        if (result) {
            cout << getMethodName() << "支付成功！" << endl;
        } else {
            cout << getMethodName() << "支付失败！" << endl;
        }
        return result;
    }
};

// --------------- 抽象化角色2：支付场景（PayScene）---------------
// 支付场景接口：持有支付方式引用，扩展场景相关逻辑
class PayScene {
protected:
    PayMethod* method_; // 桥接：关联支付方式
public:
    PayScene(PayMethod* method) : method_(method) {}
    virtual ~PayScene() {}
    // 获取场景名称
    virtual string getSceneName() const = 0;
    // 场景化支付（包含场景特定逻辑，如校验场景权限）
    virtual bool scenePay(double amount) const = 0;
};

// 扩展抽象化角色2：APP支付场景
class AppPay : public PayScene {
public:
    using PayScene::PayScene;

    string getSceneName() const override {
        return "APP支付";
    }

    bool scenePay(double amount) const override {
        cout << "\n【场景：" << getSceneName() << "】" << endl;
        // 场景特定逻辑：校验APP版本（模拟）
        cout << "校验APP版本：v2.0.0（符合支付要求）" << endl;
        // 调用支付方式的支付接口
        return method_->pay(amount);
    }
};

// 扩展抽象化角色2：H5支付场景
class H5Pay : public PayScene {
public:
    using PayScene::PayScene;

    string getSceneName() const override {
        return "H5支付";
    }

    bool scenePay(double amount) const override {
        cout << "\n【场景：" << getSceneName() << "】" << endl;
        // 场景特定逻辑：校验浏览器类型（模拟）
        cout << "校验浏览器：Chrome（支持H5支付）" << endl;
        return method_->pay(amount);
    }
};

// 扩展抽象化角色2：小程序支付场景
class MiniProgramPay : public PayScene {
public:
    using PayScene::PayScene;

    string getSceneName() const override {
        return "小程序支付";
    }

    bool scenePay(double amount) const override {
        cout << "\n【场景：" << getSceneName() << "】" << endl;
        // 场景特定逻辑：校验小程序权限（模拟）
        cout << "校验小程序权限：已授权（可发起支付）" << endl;
        return method_->pay(amount);
    }
};

// --------------- 客户端调用 ---------------
int main() {
    // 1. 创建支付渠道（实现化角色）
    PayChannel* formalChannel = new FormalChannel();
    PayChannel* testChannel = new TestChannel();

    // 2. 创建支付方式（抽象化角色1），关联支付渠道
    PayMethod* weChatFormal = new WeChatPay(formalChannel);
    PayMethod* aliTest = new Alipay(testChannel);
    PayMethod* unionFormal = new UnionPay(formalChannel);

    // 3. 创建支付场景（抽象化角色2），关联支付方式
    PayScene* appWeChat = new AppPay(weChatFormal);
    PayScene* h5Ali = new H5Pay(aliTest);
    PayScene* miniUnion = new MiniProgramPay(unionFormal);

    // 4. 发起场景化支付
    appWeChat->scenePay(199.9);    // APP场景-正式环境-微信支付，金额199.9元
    h5Ali->scenePay(99.0);         // H5场景-测试环境-支付宝支付，金额99元
    miniUnion->scenePay(299.5);    // 小程序场景-正式环境-银联支付，金额299.5元

    // 5. 释放资源
    delete appWeChat;
    delete h5Ali;
    delete miniUnion;
    delete weChatFormal;
    delete aliTest;
    delete unionFormal;
    delete formalChannel;
    delete testChannel;

    return 0;
}

3. 代码解析与扩展说明

运行效果：程序会输出不同场景、不同支付方式、不同渠道的支付流程，包含场景校验、渠道调用、支付结果反馈；
多维度桥接：通过PayScene持有PayMethod、PayMethod持有PayChannel，实现了 “场景 - 支付方式 - 渠道” 三个维度的解耦；
扩展灵活性：新增支付方式（如京东支付）只需新增JDPay类继承PayMethod，新增场景（如 PC 支付）只需新增PCPay类继承PayScene，完全不影响原有代码；
实际价值：在真实支付系统中，测试环境和正式环境的切换、不同场景的权限校验、不同支付方式的接口差异，都可以通过这种方式解耦，代码结构清晰，维护成本低。

五、C++ 实战示例 3：框架级应用（桥接模式 + 工厂模式）

在实际项目中，桥接模式常与其他设计模式结合使用，比如工厂模式（用于创建对象，隐藏创建细节）。下面我们实现一个 “日志框架”，结合桥接模式和简单工厂模式，支持：

抽象维度：日志类型（文件日志、控制台日志）；
实现维度：日志格式（普通格式、JSON 格式）；
工厂模式：创建日志对象，客户端无需直接 new 对象。

1. 完整 C++ 代码

#include <iostream>
#include <fstream>
#include <string>
#include <ctime>
using namespace std;

// --------------- 实现化角色：日志格式（LogFormatter）---------------
class LogFormatter {
public:
    virtual ~LogFormatter() {}
    // 格式化日志内容（包含时间、级别、消息）
    virtual string format(const string& level, const string& message) const = 0;
};

// 具体实现化角色：普通格式
class PlainFormatter : public LogFormatter {
public:
    string format(const string& level, const string& message) const override {
        // 格式：[时间] [级别] 消息
        time_t now = time(nullptr);
        char timeStr[64];
        strftime(timeStr, sizeof(timeStr), "%Y-%m-%d %H:%M:%S", localtime(&now));
        return "[" + string(timeStr) + "] [" + level + "] " + message;
    }
};

// 具体实现化角色：JSON格式
class JsonFormatter : public LogFormatter {
public:
    string format(const string& level, const string& message) const override {
        // 格式：{"time":"时间","level":"级别","message":"消息"}
        time_t now = time(nullptr);
        char timeStr[64];
        strftime(timeStr, sizeof(timeStr), "%Y-%m-%d %H:%M:%S", localtime(&now));
        return "{\"time\":\"" + string(timeStr) + "\",\"level\":\"" + level + "\",\"message\":\"" + message + "\"}";
    }
};

// --------------- 抽象化角色：日志器（Logger）---------------
class Logger {
protected:
    LogFormatter* formatter_; // 桥接：关联日志格式
public:
    Logger(LogFormatter* formatter) : formatter_(formatter) {}
    virtual ~Logger() {}
    // 日志级别：DEBUG、INFO、ERROR
    virtual void debug(const string& message) = 0;
    virtual void info(const string& message) = 0;
    virtual void error(const string& message) = 0;
protected:
    // 通用日志输出方法（模板方法）
    virtual void log(const string& level, const string& message) = 0;
};

// 扩展抽象化角色：控制台日志器
class ConsoleLogger : public Logger {
public:
    using Logger::Logger;

    void debug(const string& message) override {
        log("DEBUG", message);
    }

    void info(const string& message) override {
        log("INFO", message);
    }

    void error(const string& message) override {
        log("ERROR", message);
    }

protected:
    void log(const string& level, const string& message) override {
        // 格式化日志并输出到控制台
        string logMsg = formatter_->format(level, message);
        cout << "[Console] " << logMsg << endl;
    }
};

// 扩展抽象化角色：文件日志器
class FileLogger : public Logger {
private:
    string filename_; // 日志文件名
public:
    FileLogger(LogFormatter* formatter, const string& filename) 
        : Logger(formatter), filename_(filename) {}

    void debug(const string& message) override {
        log("DEBUG", message);
    }

    void info(const string& message) override {
        log("INFO", message);
    }

    void error(const string& message) override {
        log("ERROR", message);
    }

protected:
    void log(const string& level, const string& message) override {
        // 格式化日志并写入文件
        string logMsg = formatter_->format(level, message);
        ofstream file(filename_, ios::app); // 追加模式写入
        if (file.is_open()) {
            file << "[File] " << logMsg << endl;
            file.close();
            cout << "日志已写入文件：" << filename_ << endl;
        } else {
            cerr << "文件打开失败：" << filename_ << endl;
        }
    }
};

// --------------- 简单工厂模式：日志工厂（LoggerFactory）---------------
// 日志类型枚举
enum class LoggerType {
    CONSOLE, // 控制台日志
    FILE    // 文件日志
};

// 日志格式枚举
enum class FormatterType {
    PLAIN,  // 普通格式
    JSON    // JSON格式
};

class LoggerFactory {
public:
    // 静态工厂方法：创建日志器
    static Logger* createLogger(LoggerType loggerType, FormatterType formatterType, const string& filename = "app.log") {
        // 1. 创建日志格式对象（实现化角色）
        LogFormatter* formatter = nullptr;
        switch (formatterType) {
            case FormatterType::PLAIN:
                formatter = new PlainFormatter();
                break;
            case FormatterType::JSON:
                formatter = new JsonFormatter();
                break;
            default:
                throw invalid_argument("不支持的日志格式类型");
        }

        // 2. 创建日志器对象（抽象化角色），关联日志格式
        Logger* logger = nullptr;
        switch (loggerType) {
            case LoggerType::CONSOLE:
                logger = new ConsoleLogger(formatter);
                break;
            case LoggerType::FILE:
                logger = new FileLogger(formatter, filename);
                break;
            default:
                delete formatter; // 避免内存泄漏
                throw invalid_argument("不支持的日志器类型");
        }

        return logger;
    }

    // 静态方法：释放日志器资源
    static void destroyLogger(Logger* logger) {
        if (logger) {
            delete logger;
        }
    }
};

// --------------- 客户端调用 ---------------
int main() {
    try {
        // 1. 创建控制台日志器（普通格式）
        Logger* consoleLogger = LoggerFactory::createLogger(
            LoggerType::CONSOLE, FormatterType::PLAIN
        );
        consoleLogger->debug("初始化配置文件");
        consoleLogger->info("系统启动成功");
        consoleLogger->error("数据库连接失败");

        // 2. 创建文件日志器（JSON格式）
        Logger* fileLogger = LoggerFactory::createLogger(
            LoggerType::FILE, FormatterType::JSON, "system.log"
        );
        fileLogger->debug("加载插件：支付插件");
        fileLogger->info("用户登录：username=test");
        fileLogger->error("接口调用失败：/api/pay");

        // 3. 释放资源
        LoggerFactory::destroyLogger(consoleLogger);
        LoggerFactory::destroyLogger(fileLogger);
    } catch (const exception& e) {
        cerr << "创建日志器失败：" << e.what() << endl;
        return 1;
    }

    return 0;
}

3. 代码解析与实际价值

模式结合：桥接模式解耦 “日志类型” 和 “日志格式”，工厂模式隐藏对象创建细节，客户端无需关心对象如何创建，只需调用工厂方法；
实际应用：这个日志框架在真实项目中可直接复用，支持控制台 / 文件日志切换、普通 / JSON 格式切换，新增日志类型（如网络日志）或格式（如 XML 格式）只需新增对应类，扩展灵活；
代码质量：通过工厂模式统一管理对象创建和销毁，避免内存泄漏；桥接模式让代码结构清晰，降低耦合度，符合 “单一职责原则”（每个类只负责一个维度的逻辑）。

六、桥接模式的应用场景与优缺点

1. 典型应用场景

桥接模式的核心是 “解耦多维度独立变化”，以下场景优先考虑使用：

存在两个或多个独立变化的维度，且这些维度需要独立扩展（如形状 + 颜色、支付方式 + 场景 + 渠道、日志类型 + 格式）；
希望避免类爆炸，减少代码冗余（如传统设计会导致类数量指数级增长的场景）；
希望通过 “组合” 替代 “继承”，降低耦合度（继承会导致类层级复杂，耦合度高）；
需在运行时动态切换实现（如支付系统在测试环境和正式环境之间切换）。

2. 优点

解耦抽象与实现：抽象维度和实现维度完全分离，各自独立扩展，符合 “开闭原则”；
避免类爆炸：类数量呈线性增长，而非指数级增长，降低维护成本；
提高扩展性：新增维度或维度下的具体实现，无需修改原有代码；
运行时动态切换：通过修改桥接的关联对象，可在运行时切换不同的实现（如日志格式从普通格式切换为 JSON 格式）。

3. 缺点

增加代码复杂度：需要拆分维度，定义多个抽象类和实现类，对新手不友好；
设计难度提升：需要准确识别出独立变化的维度，否则可能过度设计；
对象管理成本：客户端需要管理多个维度的对象生命周期，容易出现内存泄漏（可通过工厂模式、智能指针优化）。

七、桥接模式与其他设计模式的区别

很多开发者会混淆桥接模式与装饰器模式、策略模式，这里用通俗的语言讲清它们的核心区别：

1. 桥接模式 vs 装饰器模式

核心目的不同：
- 桥接模式：解耦 “抽象维度” 和 “实现维度”，支持维度的独立扩展；
- 装饰器模式：在不改变原类结构的前提下，动态给对象增加功能（增强对象能力）。
关系不同：
- 桥接模式：抽象类和实现类是 “组合关系”（桥接关联）；
- 装饰器模式：装饰器和被装饰者是 “聚合关系”（包装关系）。
示例对比：
- 桥接模式：圆形（抽象）+ 红色（实现），两者是独立维度；
- 装饰器模式：给圆形（被装饰者）增加 “发光效果”（装饰器），增强圆形的功能。

2. 桥接模式 vs 策略模式

核心目的不同：
- 桥接模式：关注 “多维度独立变化”，每个维度都有多个具体实现，且维度之间是平等的；
- 策略模式：关注 “算法替换”，核心是选择不同的算法（策略）完成同一个任务，算法之间是互斥的。
结构不同：
- 桥接模式：有两个（或多个）抽象类层级（如形状层级、颜色层级）；
- 策略模式：只有一个抽象策略类层级，客户端通过注入不同的策略对象切换算法。
示例对比：
- 桥接模式：支付方式（微信、支付宝）+ 支付场景（APP、H5），两者是平等的维度；
- 策略模式：排序算法（冒泡排序、快速排序），选择不同算法完成排序任务。