设计模式之桥接模式 (Bridge Pattern)

📋 Research Summary

桥接模式是处理"多维度变化"的经典方案。在 GUI 框架（如 Java AWT、Flutter）中广泛应用，将"控件类型"与"渲染平台"两个维度分离。与适配器模式"事后补救"不同，桥接模式是"事前设计"。

---

🌱 逻辑原点

如果你要绘制不同形状（圆形、方形、三角形），每种形状又有不同颜色（红、绿、蓝），继承会创造 9 个类；如果增加一个"边框样式"维度，类数量会爆炸到 27 个。如何避免这种组合爆炸？

多维度扩展与类数量控制的矛盾：每个维度独立变化，但继承强制将它们绑定在一起。

🧠 苏格拉底式对话

1️⃣ 现状：最原始的解法是什么？

使用多重继承：

class RedCircle(Circle, Red): ...
class BlueCircle(Circle, Blue): ...
class RedSquare(Square, Red): ...
# 每增加一个形状或颜色，都要创建新类

优点 ：直观，每个类代表一种具体组合。
问题：类数量随维度乘积增长，代码重复严重。

2️⃣ 瓶颈：规模扩大 100 倍时会在哪里崩溃？

当维度增加到 4 个（形状、颜色、边框、填充模式），每个维度有 5 个选项时：

• 类爆炸：5^4 = 625 个类！（计算公式：选项数^维度数）
• 代码重复 ：所有圆形类都要重复实现 draw_circle 逻辑
• 修改困难：改变圆形的绘制方式，需要修改所有圆形子类
• 无法运行时组合：编译时就已经确定了组合，无法动态切换

核心矛盾：继承是静态的、紧耦合的，但业务需求是多维度的、动态组合的。

3️⃣ 突破：必须引入什么新维度？

用组合替代继承，将维度分离。

不是"圆形是一种红色图形"，而是"圆形有一个颜色属性"。形状是一个维度，颜色是另一个维度，它们通过组合关联：

形状（抽象）--持有--> 颜色（实现）
  |                      |
圆形、方形           红色、蓝色

这就是桥接的本质：将继承层次转变为组合关系，让维度独立演化。

📊 视觉骨架

组合 compose
继承 extend
继承 extend
实现 implement
实现 implement
<<abstract>>
Shape
#color: Color
+draw()
+applyColor()
<<interface>>
Color
+applyColor()
Circle
+draw()
Square
+draw()
Red
+applyColor()
Blue
+applyColor()

关键洞察 ：桥接模式创造了两个独立的继承层次。抽象部分 （形状）与实现部分（颜色）分离，通过一座"桥"（组合关系）连接，使它们可以独立变化。

⚖️ 权衡模型

公式：

Bridge = 解决了多维度组合爆炸 + 牺牲了直观性 + 增加了设计复杂度

代价分析：

• ✅ 解决： 维度独立扩展、运行时动态组合、减少类数量（从乘积变为求和）
• ❌ 牺牲： 直观性（需要理解两个层次的关系）、简单的创建变得复杂（需要组装两个对象）
• ⚠️ 增加： 设计复杂度（需要识别维度并分离）、间接调用开销

使用建议：当一个类需要在两个或多个独立维度上扩展时使用。典型的"抽象-实现"分离场景：GUI（控件-平台）、设备驱动（设备-操作系统）、消息发送（消息-通道）。

🔁 记忆锚点

class Shape(ABC):
    """
    桥接的本质：将多维度继承转变为组合
    """
    
    def __init__(self, color: "Color"):
        # "桥"：通过组合连接另一个维度
        self._color = color
    
    @abstractmethod
    def draw(self) -> None:
        pass
    
    def apply_color(self) -> None:
        # 委托给另一个维度的实现
        self._color.apply()

class Circle(Shape):
    def draw(self) -> None:
        print("Drawing circle")
        self.apply_color()

# 运行时自由组合
red_circle = Circle(RedColor())
blue_circle = Circle(BlueColor())  # 同一个类，不同行为

一句话本质： 桥接模式 = 将"是一种"转变为"有一个"，让维度独立演化。

---