桥接模式通过组合代替继承分离抽象与实现，使二者独立演化；抽象类（如Shape）定义高层行为并委托给实现接口（如Color），运行时可动态替换具体实现，接口窄而稳定，职责清晰，适用于多维度变化导致类爆炸的场景。
桥接模式通过“组合代替继承”把抽象和实现拆开，让两者能各自演化、互不干扰。
抽象类持有实现接口的引用
抽象类（比如 Shape）不直接实现具体逻辑，而是定义高层行为（如 draw()），内部声明一个实现接口（如 Color）类型的成员变量。它不做颜色填充、不画像素，只负责协调流程——调用 color.fill() 或 renderer.draw() 这类委托操作。
- 构造时传入具体实现对象，例如 new Circle(new Red())
- 运行中可随时替换，比如 circle.setColor(new Green())，下次 draw 就生效
- 接口窄而稳定，比如 Color 只需一个 fill() 方法，不暴露内部结构
两层结构各自独立扩展
抽象层管“做什么”，实现层管“怎么做”。新增图形（Triangle）只需继承 Shape；新增颜色（Yellow）或渲染引擎（OpenGLRenderer）只需实现对应接口。二者不交叉，也不生成组合子类。
- 加一种形状：写一个新 Shape 子类，复用全部已有颜色和渲染器
- 加一种颜色：写一个新 Color 实现类，所有形状自动支持该颜色
- 加一种平台适配：新增 ConcreteImplementor，不影响任何 Abstraction
明确划分职责边界
抽象部分聚焦业务语义（如“绘制一个带边框的圆”），实现部分专注技术细节（如“用 OpenGL 绘制圆形顶点”或“用 SVG 输出 path 标签”）。它们之间只通过清晰、有限的接口通信，比如一个方法或一组方法，不共享状态、不依赖对方内部实现。
- Abstraction 不知道 Red 是怎么实现 fill() 的
- ConcreteImplementor 不关心自己被哪个 Shape 使用
- 接口设计以最小必要为原则，避免过度耦合
适用场景判断要点
当系统出现两个或多个变化维度，且这些维度组合后会导致类数量爆炸时，桥接模式就该出场了。典型信号包括：
- 类名开始出现类似 “CircleRedOpenGL”、“SquareBlueVulkan” 这样的长命名
- 每次新增一个维度（如新图形 + 新颜色 + 新平台），就得补一堆子类
- 希望运行时切换底层实现（比如从本地绘图切到远程渲染）
- 需要跨平台复用同一套业务逻辑，但底层 API 差异很大
