📋 Research Summary
桥接模式是处理"多维度变化"的经典方案。在 GUI 框架(如 Java AWT、Flutter)中广泛应用,将"控件类型"与"渲染平台"两个维度分离。与适配器模式"事后补救"不同,桥接模式是"事前设计"。
🌱 逻辑原点
如果你要绘制不同形状(圆形、方形、三角形),每种形状又有不同颜色(红、绿、蓝),继承会创造 9 个类;如果增加一个"边框样式"维度,类数量会爆炸到 27 个。如何避免这种组合爆炸?
多维度扩展与类数量控制的矛盾:每个维度独立变化,但继承强制将它们绑定在一起。
🧠 苏格拉底式对话
1️⃣ 现状:最原始的解法是什么?
使用多重继承:
python
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(控件-平台)、设备驱动(设备-操作系统)、消息发送(消息-通道)。
🔁 记忆锚点
python
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()) # 同一个类,不同行为
一句话本质: 桥接模式 = 将"是一种"转变为"有一个",让维度独立演化。