## 01、痛点

我是老李，之前在团队里接手过一个消息通知服务。最早需求只有一条：普通消息发短信。代码大概长这样：

```java
public void send(String content) {
    System.out.println("短信发送：" + content);
}
```

后来产品说加邮件，又加钉钉，再加紧急消息。年轻同事开始改，很快变成一坨：

```java
public void send(String type, String channel, String content) {
    if (type.equals("normal")) {
        if (channel.equals("sms")) {
            System.out.println("短信发送：" + content);
        } else if (channel.equals("email")) {
            System.out.println("邮件发送：" + content);
        } else if (channel.equals("dingtalk")) {
            System.out.println("钉钉发送：" + content);
        }
    } else if (type.equals("urgent")) {
        if (channel.equals("sms")) {
            System.out.println("短信发送加急：" + content);
        } else if (channel.equals("email")) {
            System.out.println("邮件发送加急：" + content);
        } else if (channel.equals("dingtalk")) {
            System.out.println("钉钉发送加急：" + content);
        }
    }
}
```

有人觉得 if/else 太难看，改用继承，一顿操作后变成六个类：

```
Message
├── NormalMessage
│   ├── NormalSmsMessage
│   ├── NormalEmailMessage
│   └── NormalDingTalkMessage
└── UrgentMessage
    ├── UrgentSmsMessage
    ├── UrgentEmailMessage
    └── UrgentDingTalkMessage
```

需求说加一个微信渠道，结果新增两个子类；再加一种定时消息，又新增三个渠道子类。类直接爆炸。

> 锐评：两个类型、三个渠道，继承已经开始造类；等类型和渠道都变成两位数，这个模块可以直接开动物园。

这暴露了什么？不是 if/else 写得差，也不是继承不能用，而是两个独立变化的维度被强行耦合在一起，互相放大。设计模式要解决的，就是这种“变化开始失控”。

## 02、是什么

桥接模式，Engineering 视角就一句话：把抽象部分和实现部分分离，让它们各自独立变化。不要背定义，先理解这里的“抽象部分”和“实现部分”到底指什么。

在刚才的消息案例里：
- 抽象部分：消息类型（普通、紧急），它关心“消息怎么表示”。
- 实现部分：发送渠道（短信、邮件、钉钉），它关心“消息怎么送达”。

两个维度原本相互独立，但继承写法把它们捆成一棵树，导致每一次组合都产生类。桥接模式用组合代替继承，把两个维度拆成两条线，通过一个引用连起来。

角色关系如下：

```
Abstraction（抽象部分：Message）
    |
    | 持有
    v
Implementor（实现部分：MessageSender）
    ^
    | 实现
ConcreteImplementor（具体实现：SmsSender / EmailSender / DingTalkSender）
```

- `Abstraction`：定义高层操作，持有一个`Implementor`引用。
- `RefinedAbstraction`：扩展抽象，比如`NormalMessage`、`UrgentMessage`。
- `Implementor`：定义底层操作接口，不关心抽象部分细节。
- `ConcreteImplementor`：具体实现，比如`SmsSender`。

桥接模式属于 GoF 结构型模式，核心是“组合优于继承”。它不是神奇公式，而是把相乘的两个维度变成相加的两条线。

## 03、为什么

很多同学学过桥接模式，但项目里不用。常见三个误区：

1. 先记模式再找场景，硬套。
2. 只看到 if/else，没看到两个维度都在变，于是只上策略模式。
3. 觉得多拆类就是好架构，为了抽象而抽象。

桥接模式不是用来优化一个双层 if/else 的。它的价值来自两个独立变化维度同时存在。判断是否值得用，问自己五个问题：

1. 是否存在两个以上独立变化的维度？
2. 每个维度的变化是否会迫使另一维度产生新类？
3. 组合数量是否已经或即将爆炸？
4. 新增一个实现或类型，是否需要改动已有类？
5. 引入桥接后，理解成本是否低于维护成本？

可以用一个简单公式：

```
模式收益 = 未来变化成本降低 - 当前抽象复杂度增加
```

如果收益是负的，就别用。

> 锐评：两个固定分支、未来三年不动的场景，硬拆成桥接，不是扩展性好，是阅读体验差。

桥接模式不是减少代码行数，而是减小修改半径：加一个渠道不改消息类型，加一个消息类型不碰渠道。

## 04、架构

在真实系统里，桥接模式通常出现在“业务类型 × 实现方式”的场景。把常见变化维度映射到模式，桥接模式解决的是：

```
需求变化
  ↓
识别变化维度
  ↓
发现两个维度独立
  ↓
抽象部分 / 实现部分分离
  ↓
组合连接
  ↓
各自扩展
```

常见问题与模式对应：

```
变化类型一：对象怎么创建？         → 工厂 / 建造者
变化类型二：多个实现怎么切换？     → 策略
变化类型三：流程怎么复用？         → 模板方法
变化类型四：多个节点怎么串？       → 责任链
变化类型五：外部系统怎么接？       → 适配器
变化类型六：功能怎么动态叠加？     → 装饰器
变化类型七：状态不同怎么改变行为？ → 状态模式
变化类型八：多个维度独立变化？     → 桥接模式
```

桥接模式和策略模式容易混淆。简单理解：
- 策略模式：单维度变化，调用方选择不同算法/实现，变化对象一般不需要再分类型。
- 桥接模式：两个维度各自变化，抽象部分有自己的继承体系，实现部分也有自己的继承体系，两者通过组合连接。

也就是说，策略通常是“换一个实现”，桥接是“抽象类型 × 实现类型都要换，还要组合”。

## 05、实战

这一节用完整案例跑一遍：消息类型（普通、紧急）× 发送渠道（短信、邮件、钉钉）。

### 一、业务场景
系统需要发送不同类型消息：普通消息正常发送；紧急消息要加“加急”标记。发送渠道有三种：短信、邮件、钉钉。两个维度未来都可能扩展。

### 二、第一版代码
最直接写法是集中判断：

```java
public class MessageService {
    public void send(String type, String channel, String content) {
        if ("normal".equals(type)) {
            if ("sms".equals(channel)) {
                System.out.println("短信发送：" + content);
            } else if ("email".equals(channel)) {
                System.out.println("邮件发送：" + content);
            } else if ("dingtalk".equals(channel)) {
                System.out.println("钉钉发送：" + content);
            }
        } else if ("urgent".equals(type)) {
            if ("sms".equals(channel)) {
                System.out.println("短信发送加急：" + content);
            } else if ("email".equals(channel)) {
                System.out.println("邮件发送加急：" + content);
            } else if ("dingtalk".equals(channel)) {
                System.out.println("钉钉发送加急：" + content);
            }
        }
    }
}
```

### 三、代码开始失控
新增微信渠道，要在两个分支里加判断；新增定时消息，要复制整个结构。类越来越长，测试越来越难，担心改一个渠道影响其他类型。

### 四、模式重构
先定义实现部分接口：

```java
public interface MessageSender {
    void send(String content);
}
```

实现三个渠道：

```java
public class SmsSender implements MessageSender {
    @Override
    public void send(String content) {
        System.out.println("短信发送：" + content);
    }
}

public class EmailSender implements MessageSender {
    @Override
    public void send(String content) {
        System.out.println("邮件发送：" + content);
    }
}

public class DingTalkSender implements MessageSender {
    @Override
    public void send(String content) {
        System.out.println("钉钉发送：" + content);
    }
}
```

再定义抽象部分：

```java
public abstract class Message {
    protected MessageSender sender;

    public Message(MessageSender sender) {
        this.sender = sender;
    }

    public abstract void send();
}
```

精化抽象：

```java
public class NormalMessage extends Message {
    public NormalMessage(MessageSender sender) {
        super(sender);
    }

    @Override
    public void send() {
        sender.send(content);
    }
}

public class UrgentMessage extends Message {
    public UrgentMessage(MessageSender sender) {
        super(sender);
    }

    @Override
    public void send() {
        sender.send("[加急] " + content);
    }
}
```

使用方式：

```java
MessageSender sms = new SmsSender();
Message normalSms = new NormalMessage(sms);
normalSms.send();

Message urgentEmail = new UrgentMessage(new EmailSender());
urgentEmail.send();
```

### 五、结构变化

传统写法是两维相乘：

```
Message
├── NormalMessage
│   ├── NormalSmsMessage
│   ├── NormalEmailMessage
│   └── NormalDingTalkMessage
└── UrgentMessage
    ├── UrgentSmsMessage
    ├── UrgentEmailMessage
    └── UrgentDingTalkMessage
```

重构后是两条线：

```
Message (抽象)
    |
    | 持有
    v
MessageSender (接口)
    ^
    | 实现
SmsSender / EmailSender / DingTalkSender
```

新增微信渠道：只需加 `WeChatSender implements MessageSender`，不影响 `Message` 及其子类。新增消息类型：只需加 `ScheduledMessage extends Message`，不影响渠道实现。

### 六、收益
- 类数量从 m×n 变为 m+n（抽象类数量 + 实现类数量，粗略）。
- 新增渠道不改消息类型代码。
- 新增消息类型不污染渠道体系。
- 消息类型和渠道职责单一，可单独测试。

### 七、代价
- 类数量相对集中 if/else 会多一些。
- 需要理解“抽象持有实现”的组合关系，阅读链路变长。
- 如果未来只有一个维度变化，桥接部分维度空转，增加复杂度。

### 八、什么时候不要用
- 只有一个维度变化，比如只是多渠道切换，用策略模式就够了。
- 两个维度变化极小且固定，比如类型和渠道都只有两个，且长期不变。
- 业务没有独立扩展需求，为了桥接而桥接。

判断口诀：**“两个维度都在变，别让继承绑死；一个维度换实现，策略也许更合适。”**

桥接模式与策略模式的区别：策略模式关注一个行为族的替换，调用方持有策略并直接使用；桥接模式关注两个层级独立变化，抽象部分持有实现部分，两者可以各自扩展并任意组合。如果说策略是“替换一个接口实现”，桥接就是“替换多个接口实现，并且接口之上还有一层类型体系”。

## 06、洞见

桥接模式表面上是拆类，背后是识别变化维度的能力。很多复杂代码不是写出来的，是“乘”出来的：两个维度一旦耦合，后续修改就是笛卡尔积。真正要锻炼的是：

- 看到需求，先分辨有几个独立变化方向。
- 好的抽象来自重复出现的变化，不是一开始就画七层架构。
- 组合优于继承不是口号，是减少耦合、降低修改半径的手段。

Spring 框架里也在不断实践组合思想，例如 `JdbcTemplate` 组合 `DataSource`，AOP 代理隔离横切逻辑。不一定每个都叫“桥接模式”，但思想类似：各自变化，互不污染。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

学习桥接模式，别先背角色，先做三阶段实践。

**第一阶段：认识核心**。搞懂 Abstraction、RefinedAbstraction、Implementor、ConcreteImplementor 四个角色，并默写一遍上面的消息案例。

**第二阶段：找项目里的坏味道**。重点找“业务类型 × 实现方式”场景，比如：
- 消息类型 × 发送渠道
- 图表类型 × 渲染器
- 订单类型 × 处理器
- 支付方式 × 通知方式

**第三阶段：动手重构**。对每个候选场景，回答五个问题：
1. 变化点是什么？
2. 不用桥接会怎样？
3. 使用桥接增加了什么复杂度？
4. 下一次新增需求，需要修改几个地方？
5. 新人是否更容易理解？

七天计划：
- Day 1：找一个存在两个维度变化的场景，画出类结构。
- Day 2：计算当前类数量，估算新增一个类型/实现会加多少类。
- Day 3：提取实现部分接口（Implementor）。
- Day 4：提取抽象部分类（Abstraction），通过组合连接。
- Day 5：重构具体实现和精化抽象。
- Day 6：新增一个实现或类型，验证不修改原有代码。
- Day 7：回看哪些重构没必要，哪些 if/else 本来就该保留。

## 08、小结

桥接模式的本质不是消灭继承，而是把两个继承树从相乘变成相加。

真正值得学的不是 Abstração 这几个英文单词，而是看到变化、识别维度、隔离耦合的能力。如果读完这篇文章，你少建了六个消息子类，这篇文章就算没白写。

## 09、链接与概念说明

- **GoF**：指 Gang of Four，即《设计模式：可复用面向对象软件的基础》四位作者。书中将模式分为创建型、结构型、行为型三类。
- **创建型模式**：解决对象怎么创建，如工厂、建造者、单例。
- **结构型模式**：解决类与对象如何组合，如桥接、适配器、装饰器、代理。
- **行为型模式**：解决对象之间职责分配与交互，如策略、模板方法、责任链、观察者。
- **桥接模式**：属于结构型，核心是分离抽象部分与实现部分，使二者独立变化。
- **组合优于继承**：来自 GoF 设计原则之一，强调用组合获得更大灵活性和更低耦合。
- **SOLID 与桥接模式**：桥接模式遵循开闭原则（对扩展开放，对修改关闭）、单一职责原则（消息类型与渠道分离）、依赖倒置原则（抽象依赖接口）。
- **区分 Bridge 与 Strategy**：桥接关注两个维度独立变化，抽象与实现均有层级；策略关注单一行为替换，通常不需要抽象部分再分层。
- **推荐资料**：《设计模式：可复用面向对象软件的基础》、《Head First设计模式》、Refactoring Guru 网站、Martin Fowler《Refactoring: Improving the Design of Existing Code》。以上资料可直接搜索名称获取，不在此虚构链接。

我是老李，之前在团队里接手过一个消息通知服务。最早需求只有一条：普通消息发短信。代码大概长这样：

《设计模式军体拳第11招》 桥接模式 Bridge——拆开两个独立变化的维度

普通/紧急消息×短信/邮件/钉钉，继承写法引发类爆炸。用桥接模式拆分抽象与实现，新增渠道不改消息类型，新增类型不污染渠道体系。

架构师

编程语言

架构设计

后端

桥接模式实战指南：消息通知服务因类型与渠道双维度耦合导致类爆炸，通过组合替代继承分离抽象与实现，实现独立扩展。本文解析模式原理、应用场景及重构步骤，助你识别变化维度，降低维护成本。

2026上云采购 | AI焕新·智启新局

tcmq

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第11招》 桥接模式 Bridge——拆开两个独立变化的维度-腾讯云开发者社区-腾讯云

《设计模式军体拳第11招》桥接模式 Bridge——拆开两个独立变化的维度

《设计模式军体拳第11招》桥接模式 Bridge——拆开两个独立变化的维度

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第11招》 桥接模式 Bridge——拆开两个独立变化的维度

《设计模式军体拳第11招》 桥接模式 Bridge——拆开两个独立变化的维度

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第11招》桥接模式 Bridge——拆开两个独立变化的维度

《设计模式军体拳第11招》桥接模式 Bridge——拆开两个独立变化的维度