桥接模式的核心目标是解耦抽象与实现以支持二者独立变化。它通过两套独立类体系、组合代替继承、运行时动态切换实现，避免类爆炸，强调正交演化而非单纯接口适配。
桥接模式（Bridge Pattern）在 C++ 中的核心目标是把抽象（Abstraction）和实现（Implementation）解耦，让两者可以独立变化。它不是为了解决“怎么连两个类”，而是为了解决“类爆炸”问题——比如有 3 种形状 × 4 种渲染方式，若用继承硬组合，就得写 12 个子类；用桥接，只需 3 个抽象类 + 4 个实现类，再通过组合动态绑定。
抽象层与实现层分离
桥接的关键是定义两套独立的类体系：一个负责高层逻辑（如 Shape、Window），另一个专注底层细节（如 Renderer、Platform）。抽象类中持有一个指向实现类的指针（通常是智能指针或裸指针），不继承实现类，只“用”它。
- 抽象基类（例如 Shape）声明业务接口（
draw()），内部保存std::unique_ptr - 实现基类（例如 Renderer）声明底层操作（
renderCircle(float r)），由具体子类（OpenGLRenderer、VulkanRenderer）实现 - 子类（如
Circle）复用抽象基类，调用m_renderer->renderCircle(...)，完全不知道底层怎么画
用组合代替继承，支持运行时切换
桥接允许你在不改抽象类的前提下，随时更换实现。比如一个窗口对象初始化时用 Win32Platform，运行中切换成 LinuxX11Platform，只要新旧实现都符合 Platform 接口即可。
- 构造时传入实现对象：
Circle circle(std::make_unique()); - 提供
setRenderer(std::unique_ptr方法，支持动态替换r) - 注意避免裸指针生命周期管理错误，优先用
std::unique_ptr或std::shared_ptr
虚析构函数与接口纯虚化
抽象基类必须有虚析构函数，否则通过基类指针 delete 派生对象会未定义行为；实现基类也应将核心方法设为纯虚，强制子类实现，避免空操作。
class Renderer { public: virtual ~Renderer() = default; virtual void renderCircle(float) = 0; };class Shape { protected: std::unique_ptrm_renderer; public: virtual ~Shape() = default; virtual void draw() = 0; }; - 不要在抽象类里写默认实现（除非明确是可选的钩子），否则容易掩盖设计意图
典型误用与规避建议
桥接常被误当成策略模式或适配器——区别在于：桥接强调“双维度变化”，且抽象与实现是长期稳定、正交演化的；策略侧重算法替换，适配器重在接口转换。
- 别把“不同数据库驱动”直接套桥接：如果上层业务根本不关心 SQL 细节，更适合用策略；若上层要同时控制查询结构 + 执行引擎（如 ORM + Driver），桥接才合适
- 避免过度设计：只有当你预见到抽象和实现都会各自扩展（比如新增图形类型 + 新增渲染 API），才值得引入桥接
- C++ 中可配合 PIMPL 习惯用法隐藏实现细节，但 PIMPL 是编译防火墙，桥接是运行时解耦，二者目的不同，勿混淆
基本上就这些。桥接模式本身不复杂，但容易忽略“正交演化”这个前提——它不是为了炫技，而是为未来留出清晰的扩展缝。
