桥接模式：分离抽象与实现

FreeGuideOnline 最新 2026-06-18

桥接模式：分离抽象与实现

桥接模式（Bridge Pattern）是一种结构型设计模式，旨在将抽象部分与它的实现部分分离，使它们可以独立变化。简单来说，就是把一个大类里容易变化的属性或行为抽取出去，通过组合的方式连接，而不是通过多层继承来扩展。

如果你发现某个类在不同维度上都会发生变化，那么继续使用继承会导致“类爆炸”——子类的数量急剧膨胀，代码越来越难以维护。桥接模式正是为了解决这一问题而生。

为什么需要桥接模式

设想一个图形编辑器：图形有形状（圆形、方形等）和颜色（红色、蓝色等）两个独立变化的维度。如果使用继承：

Shape
├── RedCircle
├── BlueCircle
├── RedSquare
└── BlueSquare

每增加一种形状或颜色，都需要新增大量子类。这种强耦合的继承关系，使得系统扩展性极差。桥接模式通过将形状和颜色拆分为两个独立的体系，再用组合关系将二者关联起来，从而优雅地解决问题。

模式结构

桥接模式包含以下四个主要角色：

Abstraction（抽象类）：定义高层操作，持有一个 Implementor 对象的引用。它可以是接口或抽象类。
RefinedAbstraction（扩展抽象类）：扩展或修改由 Abstraction 定义的操作，可以调用 Implementor 的方法。
Implementor（实现类接口）：定义实现类的接口，该接口不一定要与 Abstraction 的接口完全一致。通常只提供基本操作，而 Abstraction 会基于这些基本操作实现更高层的功能。
ConcreteImplementor（具体实现类）：具体实现 Implementor 接口，并在不同平台上完成具体操作。

类图示意：

    Abstraction          Implementor
    ──────────          ────────────
    - impl: Implementor    + operationImpl()
    ──────────          ────────────
    + operation()                ↑
           |                     |
    ───────────────     ──────────────────
    RefinedAbstraction  ConcreteImplementorA/B...
    ───────────────     ──────────────────
    + operation()           + operationImpl()

代码示例

假设我们有一个消息发送系统，消息类型（普通消息、紧急消息）和发送渠道（邮件、短信）各自独立变化。使用桥接模式。

实现类接口（消息发送渠道）

from abc import ABC, abstractmethod

class MessageSender(ABC):
    @abstractmethod
    def send(self, message: str):
        pass

具体实现类

class EmailSender(MessageSender):
    def send(self, message: str):
        print(f"发送邮件: {message}")

class SmsSender(MessageSender):
    def send(self, message: str):
        print(f"发送短信: {message}")

抽象类（消息类型）

class Message:
    def __init__(self, sender: MessageSender):
        self._sender = sender

    def dispatch(self, content: str):
        self._sender.send(content)

扩展抽象类

class UrgentMessage(Message):
    def dispatch(self, content: str):
        content = f"【紧急】{content}"
        super().dispatch(content)

客户端使用

if __name__ == "__main__":
    email_sender = EmailSender()
    sms_sender = SmsSender()

    normal_msg = Message(email_sender)
    normal_msg.dispatch("系统维护通知")

    urgent_msg = UrgentMessage(sms_sender)
    urgent_msg.dispatch("服务器宕机")

输出：

发送邮件: 系统维护通知
发送短信: 【紧急】服务器宕机

此时若要新增发送渠道（如微信）或新消息类型（如定时消息），只需添加对应的具体实现类，无需修改原有类，符合开闭原则。

桥接模式的优缺点

优点

分离了抽象接口及其实现细节，使得两部分可以各自独立扩展。
取代了多层继承，避免了“类爆炸”，系统结构更加清晰。
符合开闭原则，新增抽象或实现类时无需修改已有代码。
实现细节对客户端透明，客户端只需面向抽象编程。

缺点

增加了系统的理解与设计难度，需要正确识别出系统中两个独立变化的维度。
如果维度划分不准确，可能会使设计更加复杂。
要求抽象类需要持有实现类的引用，增加了对象的层次，可能轻微影响性能。

适用场景

在以下场景中，桥接模式可以发挥极大价值：

一个类在两个（或多个）独立维度上容易发生变化，且都需要灵活扩展。
你不想在抽象和它的具体实现之间建立固定的绑定关系，希望在运行时可以动态切换。
需要通过组合方式代替继承，以减少子类数量的爆炸式增长。
需要将类的实现细节对客户端完全隐藏，同时允许客户端在不同的实现之间切换。

典型应用如 Java 中的 JDBC API（DriverManager 作为抽象，各类数据库驱动作为实现），或图形界面框架中的组件与外观主题分离。

与其他模式的区别

与适配器模式：适配器主要用于让两个不兼容的接口能一起工作，通常发生在系统已成型的阶段；桥接模式则在设计初期就考虑将抽象与实现分离，是一种前置设计。
与装饰器模式：装饰器也是通过组合来增强功能，但其目标是动态地为对象附加职责；桥接模式则是为了分离两个变化维度。
与策略模式：策略模式强调封装一系列可互换的算法，并由客户端选择；桥接模式中“实现”部分虽然也能替换，但抽象类本身通常知道如何与实现类协作，且整体结构更关注层次的分离。

总结

桥接模式的核心思想是“将抽象与实现解耦，使两者可以沿着各自的维度独立演进”。它通过构建两个独立的类层次结构，并用组合关系进行连接，让系统在扩展时无需承受“类爆炸”的痛苦。

当你在设计时发现某些概念可以从不同角度进行分类，且这些分类会同时变化，不妨考虑为它们搭建一座“桥”——这就是桥接模式最大的用武之地。记住，好的设计不是一开始就穷尽所有未来，而是为变化留出足够的空间。