81、STL与桥接模式：抽象与实现分离、接口设计、扩展性

桥接模式，说白了就是把「抽象」和「实现」拆开，让它们各自独立演化。你想想看，我们写代码最怕什么？最怕改一处牵动全身。桥接模式就是解决这个问题的利器。

我个人习惯把桥接模式理解为「接口的接口」。什么意思呢？就是你的高层代码只跟抽象接口打交道，具体的实现细节被藏在另一层接口后面。这样两边都能独立变化，互不干扰。

桥接模式的核心思想

先看一个我早年踩过的坑。那时候做一个图形绘制系统，需要支持圆形、矩形、三角形，每种形状又需要支持 OpenGL、DirectX、Vulkan 三种渲染后端。如果直接用继承，那就是 3×3=9 个类。再加一种形状或后端，类数量就爆炸了。

桥接模式怎么解决？把「形状」和「渲染器」拆成两个独立的继承体系：

// 渲染器接口（实现部分）
class Renderer {
public:
    virtual ~Renderer() = default;
    virtual void renderCircle(float x, float y, float r) = 0;
    virtual void renderRect(float x, float y, float w, float h) = 0;
};

// 具体渲染器
class OpenGLRenderer : public Renderer {
public:
    void renderCircle(float x, float y, float r) override {
        // OpenGL 绘制圆的代码
    }
    void renderRect(float x, float y, float w, float h) override {
        // OpenGL 绘制矩形的代码
    }
};

class DirectXRenderer : public Renderer {
    // 类似实现
};

// 形状抽象（抽象部分）
class Shape {
protected:
    Renderer* renderer_;  // 桥接的关键：持有实现接口的指针
public:
    explicit Shape(Renderer* r) : renderer_(r) {}
    virtual ~Shape() = default;
    virtual void draw() = 0;
};

// 具体形状
class Circle : public Shape {
    float x_, y_, r_;
public:
    Circle(Renderer* r, float x, float y, float rad)
        : Shape(r), x_(x), y_(y), r_(rad) {}
    void draw() override {
        renderer_->renderCircle(x_, y_, r_);
    }
};

class Rectangle : public Shape {
    // 类似实现
};

这样，新增一种形状只需要继承 Shape，新增一种渲染器只需要继承 Renderer。两边互不依赖，扩展起来非常舒服。

STL 中的桥接模式影子

你可能会问：STL 里有没有桥接模式？其实 STL 的设计哲学里处处都有这种思想。最典型的就是 迭代器。

迭代器把「遍历算法」和「容器实现」拆开了。算法只依赖迭代器接口，不关心底层是 vector、list 还是 map。这就是桥接模式在 STL 中的体现。

核心要点：桥接模式在 STL 中的体现就是「算法与容器的解耦」。迭代器就是那座桥。

再看一个例子——std::function。它把「调用方」和「被调用对象」拆开了。调用方只看到 std::function 这个抽象接口，背后可以是普通函数、lambda、函数对象、成员函数指针。这不就是桥接吗？

// 抽象接口
using Task = std::function<void()>;

// 具体实现1：普通函数
void cleanCache() { /* ... */ }

// 具体实现2：lambda
auto logTask = []() { std::cout << "logging...\n"; };

// 具体实现3：函数对象
struct BackupTask {
    void operator()() { /* 备份逻辑 */ }
};

// 调用方只跟 Task 打交道
void executeTask(const Task& t) {
    t();  // 不关心具体实现
}

嗯，这里要注意：std::function 内部用了类型擦除（type erasure），本质上就是一种桥接模式的变体。它把「调用语义」和「具体可调用对象」分离了。

接口设计的最佳实践

桥接模式对接口设计有很高的要求。我总结了几条经验：

  • 接口要小：每个接口只做一件事。比如 Renderer 只负责渲染，不要让它管理窗口或处理输入。
  • 接口要稳定：一旦发布，尽量不改。新增功能通过派生新接口实现，而不是修改现有接口。
  • 接口要抽象：不要暴露实现细节。比如不要传 OpenGL 特有的纹理 ID 给 Renderer 接口。

我的习惯：设计接口时，先写使用代码，再写接口定义。这样能保证接口是从使用者角度出发的，而不是从实现者角度。

扩展性：桥接模式的最大价值

桥接模式最让我喜欢的地方，就是它的扩展性。我曾经维护过一个日志系统，支持文件日志、控制台日志、网络日志。后来需要加一个「加密日志」功能——日志内容先加密再输出。

如果用继承，我得给每种日志类型都加一个加密版本。但用了桥接模式，我只需要新增一个 EncryptedLogger 类，它包装一个已有的 Logger 对象，在写入前加密即可：

class EncryptedLogger : public Logger {
    Logger* wrapped_;
public:
    explicit EncryptedLogger(Logger* w) : wrapped_(w) {}
    void write(const std::string& msg) override {
        std::string encrypted = encrypt(msg);
        wrapped_->write(encrypted);
    }
};

你看，不需要改任何现有代码，就实现了新功能。这就是桥接模式对「开闭原则」的完美支持。

桥接模式与策略模式的区别

很多人容易把桥接和策略搞混。我简单说一下：

维度 桥接模式 策略模式
关注点 抽象与实现分离 算法可替换
结构 两个独立的继承体系 一个上下文 + 多个策略
变化方向 抽象和实现各自变化 策略算法变化
典型场景 跨平台渲染、多数据库支持 排序算法选择、支付方式选择

说白了，桥接是「结构型」模式，策略是「行为型」模式。桥接解决的是「怎么组织类结构」，策略解决的是「怎么选择行为」。

SVG 结构图：桥接模式的核心逻辑

桥接模式结构图 Shape（抽象） + draw() Circle Rectangle 桥接：持有 Renderer* Renderer（实现） + renderCircle() + renderRect() OpenGL DirectX 抽象部分（形状） 实现部分（渲染器） 两者通过组合关系连接，各自独立变化 新增形状或渲染器，无需修改现有代码

避坑指南

我曾经犯过的错：在一个项目中，我把桥接模式的接口设计得太细了。每个方法都有十几个参数，结果实现类之间大量重复代码。后来我重构了接口，把相关参数封装成结构体，接口一下子清爽了很多。

还有一点：不要滥用桥接模式。如果你的抽象和实现只有一种变化方向，或者未来几乎不会扩展，那用简单的继承就够了。桥接模式会增加代码复杂度，得不偿失。

我个人判断是否使用桥接模式的标准很简单：问自己两个问题——抽象部分会不会有多种变体？实现部分会不会有多种变体？如果两个答案都是「是」，那就用桥接。否则，别用。

总结

桥接模式的核心价值，就是让抽象和实现可以各自独立演化。STL 中的迭代器、std::function 都是这种思想的体现。设计接口时，记得保持小、稳定、抽象。扩展时，优先考虑组合而非继承。

嗯，最后说一句：模式是死的，人是活的。别为了用模式而用模式，理解背后的思想，比记住类图重要得多。

← 上一章 📖 返回目录 下一章 →