桥接模式：让C++里的“形状”和“画笔”不再互相绑架

写过图形渲染模块的同学大概都踩过这个坑：你刚给Circle类加上drawOpenGL()，产品经理说下个版本要支持Vulkan；你把Rectangle的render()改成虚函数，结果发现Text对象也得跟着改——明明只是换了个渲染后端，却要动十几处类定义。这不是设计，这是“牵一发而动全身”的连锁反应。

桥接模式（Bridge Pattern）不是教科书里那个“抽象与实现分离”的标准答案，它是C++开发者在真实项目中反复被逼出来的解耦策略：当两个维度的变化频率不同、且彼此不该知道对方细节时，就该让它们各走各的路，只通过一个稳定的接口握手。

先看一个典型坏味道：

class Shape {
public:
    virtual void draw() = 0;
};

class Circle : public Shape {
public:
    void draw() override { 
        // 直接调用 OpenGL 函数
        glDrawArrays(GL_TRIANGLE_FAN, ...); 
    }
};

问题不在Circle本身，而在它同时承担了“是什么形状”和“怎么画出来”两件事。一旦你要加Metal支持，就得新建一套CircleMetal、RectangleMetal……类爆炸不说，所有形状逻辑还得复制一遍——这哪是面向对象，这是面向复制粘贴。

桥接模式的破局点很朴素：把“变的部分”拆出去，让它独立演化。
我们不把渲染方式塞进形状里，而是让形状持有一个“渲染器”的指针：

// 实现维度：怎么画？（可独立变化）
class Renderer {
public:
    virtual void drawCircle(float x, float y, float r) = 0;
    virtual void drawRect(float x, float y, float w, float h) = 0;
    virtual ~Renderer() = default;
};

class OpenGLRenderer : public Renderer {
    void drawCircle(...) override { glDrawArrays(...); }
};

class VulkanRenderer : public Renderer {
    void drawCircle(...) override { vkCmdDraw(...); }
};

// 抽象维度：画什么？（另一条变化线）
class Shape {
protected:
    Renderer* m_renderer; // 持有实现，但不依赖具体类型
public:
    explicit Shape(Renderer* r) : m_renderer(r) {}
    virtual void draw() = 0;
};

class Circle : public Shape {
    float m_x, m_y, m_r;
public:
    Circle(Renderer* r, float x, float y, float r) 
        : Shape(r), m_x(x), m_y(y), m_r(r) {}

    void draw() override {
        m_renderer->drawCircle(m_x, m_y, m_r); // 只调用接口，不碰OpenGL/Vulkan
    }
};

这里的关键不是语法，而是职责切割的意识：

• Renderer子类负责“如何适配不同API”，它可能需要管理命令缓冲区、管线状态，甚至做平台差异封装；
• Shape子类专注“几何语义”，比如Circle::scale()只需改半径，Polygon::addVertex()只管顶点数据——它们完全不用关心自己最终是被glDrawElements还是vkQueueSubmit画出来的。

有人会问：“用模板不也能解耦？”
可以，但模板在编译期绑定，而桥接模式在运行时组合。真正需要动态切换渲染后端（比如用户设置里切OpenGL/Vulkan）、或热插拔绘制风格（线稿/阴影/描边）时，虚函数+指针才是能落地的方案。 模板解决的是泛型，桥接解决的是多态组合。

另一个常被忽略的实战细节：桥接不是单向依赖。
实际项目里，Renderer有时需要反查Shape的元信息——比如TextRenderer要读取Text::getFont()，但又不能让Renderer依赖所有Shape子类。这时可以加一层轻量接口：

class ShapeInfo {
public:
    virtual const std::string& getType() const = 0;
    virtual bool isFilled() const = 0;
    virtual ~ShapeInfo() = default;
};

// Shape 同时继承 Shape 和 ShapeInfo
class Circle : public Shape, public ShapeInfo {
    // ...
    const std::string& getType() const override { return "circle"; }
};

这样Renderer只依赖ShapeInfo，既拿到必要信息，又不污染核心抽象层。

最后提醒一个容易翻车的点：别为了桥接而桥接。
如果整个系统只有一种渲染方式，且未来三年都不会变，硬上桥接就是给自己加虚函数调用开销和指针间接寻址——C++不是Java，我们得对每行代码的代价心里有数。桥接的价值，永远体现在“变化真正发生时，你改了几处”。

下次当你发现某个类名开始出现XXXOpenGL、XXXVulkan后缀，或者#ifdef VK_ENABLE像补丁一样贴满代码时，停一下。那不是技术债，那是桥接模式在敲门：它不承诺减少代码量，但它保证——当新需求来临时，你只需要新增一个Renderer子类，而不是重写整个图形模块。

真正的解耦，不是让代码看起来更“优雅”，而是让你在凌晨三点改完Vulkan适配后，还能安心合上电脑，知道明天加个WebGPU支持，也只是再写一个WebGPURenderer而已。