gof-bridge

一句话概述

将抽象与其实现解耦，使两者可以独立变化——通过沿两个正交维度组合，取代子类数量激增的问题。

何时使用此技能

• 存在两个正交的变化维度：N 种形状 × M 种渲染器，或 N 种绘图工具 × M 种渲染后端。没有 Bridge，就会导致 N×M 个子类激增。
• 你预计抽象（例如 Shape）和实现（例如 Renderer）会随时间独立演进，也可能由不同团队维护。
• 你想在运行时切换实现——按平台、环境或配置选择不同的渲染器。

何时不应使用此技能

• 实际上只有一个维度会变化——另一个维度只有一种实现，也看不到第二种实现的需求。使用 Bridge 属于过度设计。
• 所谓的“两个维度”并非真正正交——它们会以迫使彼此耦合的方式相互作用。Bridge 的价值取决于它们是否独立。
• 你是在为两个已有的不兼容接口改造系统——这属于 gof-adapter，而不是 Bridge。Bridge 应在设计之初采用。

核心内容

两个并行的层次结构：

• 抽象——面向客户端的概念（Shape、RemoteControl、Notification）。持有对 Implementor 的引用。
• Implementor——底层接口（Renderer、Device、DeliveryChannel）。具体实现类可在运行时接入。

抽象会将具体工作委托给它持有的 Implementor。两个层次结构独立扩展：添加新的 Shape 不需要新增 Renderer 子类，反之亦然。

abstract class Shape(val renderer: Renderer) {
    abstract fun draw()
}

interface Renderer { fun renderCircle(x, y, r); fun renderSquare(x, y, s) }

class Circle(renderer: Renderer, val x, y, r): Shape(renderer) {
    override fun draw() = renderer.renderCircle(x, y, r)
}
class VectorRenderer: Renderer { ... }
class RasterRenderer: Renderer { ... }

添加新的 Shape（Triangle）时，只需定义它如何通过任何 Renderer 绘制。添加新的 Renderer（SVGRenderer）后，所有现有 Shape 都能免费支持 SVG。

Bridge 与 Adapter 的区别。 两者的组合结构相同，但意图和采用时机不同：

• Adapter 用于改造不兼容的接口——事后应用，通常位于系统边界。
• Bridge 是一种有意的设计选择，用于解耦抽象与实现——在设计之初采用，使两者都能独立变化。

判断准则

• 当两个维度都至少有 2 种变体，且你预计它们都会继续扩展时，Bridge 才有价值。
• 如果只有实现会变化，而抽象固定不变，那么你需要的是 gof-strategy，而不是 Bridge。
• 通过构造函数（或 DI）注入 Implementor，这样无需修改抽象即可替换它。

反模式

• 只有一侧实际会变化时引入 Bridge——一个抽象类加一个子类，再加一个接口和一个实现，纯属形式主义。
• Implementor 泄漏回抽象的 API 中的 Bridge——这会破坏解耦。
• 在抽象的构造函数中硬编码 Implementor 的选择——保留了 Bridge 原本要打破的耦合。

另请参阅

• gof-adapter — 结构相同的组合方式，用于改造现有的不兼容接口。
• gof-strategy — 只有一个变化维度（实现）的 Bridge。
• gof-kotlin-idioms — 在 Kotlin 中，Bridge 通常只是带接口参数的组合，无需抽象类。

参考资料

• Design Patterns（GoF，1994），第 4 章——Bridge。（未收录于 HFDP 第 2 版。）
• Kotlin Design Patterns and Best Practices（Alexey Soshin），第 3 章——Bridge。