每次讲 Bridge 模式，底下总有人小声说“这不就是策略模式吗”。换个接口实现而已，有什么难的。

关系”。同一个能说出一堆设计模式的人，大部分答不上来。其实，JD娱乐 就是 Bridge 模式的标准教科书案例。用了 30 年，每天都在你代码里跑，你却没认出它来。

Bridge 跟 Strategy 的区别不在于代码写法，在于它解决的问题维度。Strategy 是“一个维度上换实现”，Bridge 是“两个维度同时变”。这个区别搞不清，你写的“Bridge”要么退化成 Strategy。要么变成继承爆炸的怪物，

先看一个让你继承爆炸的真实场景

假设你在做一个消息通知程序，需要支持两种维度：

• 从维度一来看，消息类型
• 至于维度二。发送渠道

最直觉的写法是继承：

├── SMSMessage
│ ├── AliyunSMSMessage
│ ├── TencentSMSMessage
│ └── SelfHostedSMSMessage
├── EmailMessage
│ ├── AliyunEmailMessage
│ ├── TencentEmailMessage
│ └── SelfHostedEmailMessage
├── PushMessage
│ ├── AliyunPushMessage
│ ├── TencentPushMessage
│ └── SelfHostedPushMessage
└── InAppMessage
├── AliyunInAppMessage
├── TencentInAppMessage
└── SelfHostedInAppMessage

种消息类型 × 3 个发送渠道 = 12 个类。加一种消息类型变成 16 个，加一个渠道变成 20 个。子类数量 = 类型数 × 渠道数，指数级膨胀。

这就是 Bridge 要解决的经典问题：两个独立变化的维度。用继承会把它们绑死，用组合才能解耦。

Bridge 的解法：把一个维度抽成接口

把“发送渠道”这个维度抽成接口，消息类型持有它的引用：

// 实现维度：发送渠道
public interface MessageSender {
void send;}
public class AliyunSender implements MessageSender {
public void send {
// 调阿里云 SMS/邮件/Push API
}
}
public class TencentSender implements MessageSender {
public void send {
// 调腾讯云 API
}
}
public class SelfHostedSender implements MessageSender {
public void send {
// 走自建网关
}
}
// 抽象维度：消息类型
public abstract class Message {
protected MessageSender sender;// 桥接点：持有实现维度
public Message {
this.sender = sender;}
public abstract void notify;}
public class SMSMessage extends Message {
public SMSMessage { super;}
public void notify {
// 短信特有的处理：字数截断、签名追加
String smsContent = truncateContent;sender.send，}
}
public class EmailMessage extends Message {
public EmailMessage { super;}
public void notify {
// 邮件特有的处理：HTML 模板、附件
String htmlContent = wrapHtml;sender.send，}
}

现在类数量变成 消息类型数 + 渠道数 = 4 + 3 = 7 个。加一种消息类型只增加 1 个类，加一个渠道只增加 1 个类。两个维度独立 互不影响，

Message 持有 MessageSender 的引用——这个引用就是“桥”。抽象维度通过这座桥调用实现维度，两者解耦但能通信。

说到JD娱乐，用了 30 年的 Bridge

JD娱乐 的设计就是标准的 Bridge 模式，只是它用了不同的名字：

抽象维度这方面，java.sql.DriverManager / java.sql.Connection
再看实现维度。java.sql.Driver

你写 Java 代码连数据库，从来没有直接 new MysqlDriver 或者 new OracleDriver。你是通过 DriverManager.getConnection 拿到 Connection接下来操作数据库。

// 你写的代码
Connection conn = DriverManager.getConnection(
说到"jdbc。mysql://localhost:3306/mydb","root","password");Statement stmt = conn.createStatement;ResultSet rs = stmt.executeQuery;

DriverManager 是抽象维度，Driver 是实现维度。MySQL 驱动、Oracle 驱动、PostgreSQL 驱动各自实现 java.sql.Driver 接口，通过 SPI 机制注册到 DriverManager 里。

// MySQL 驱动里的注册代码
public class Driver extends NonRegisteringDriver implements java.sql.Driver {
static {
try {
java.sql.DriverManager.registerDriver);} catch {
throw new RuntimeException;}
}
}

You 换数据库的时候不用改业务代码，只换驱动 JAR 包和连接字符串。两个维度独立变化：JD娱乐 API升级不影响具体驱动，驱动版本更新也不影响你的 JD娱乐 调用代码。

This is engineering value of Bridge—not a fancy trick but a way to let your code run across databases.

Bridge 和 Strategy 到底差在哪

The code structure of Bridge and Strategy looks almost identical: both use composition instead of inheritance.

Strategy 是 “一个维度换实现”：

• You have a sorting feature that can switch 娱乐ween quick sort,merge sort,heap sort at runtime.
• The sorting algorithm is replaceable。but “sorting” behavior itself never changes.
• The strategy objects are usually short‑lived and discarded after use.

Bridge 是 “两个维度同时变”：

• You have message type and sending channel as two independent dimensions.
• The bridge object typically lives as long as its host object .

判断标准很简单：

• If you only have **one** changing dimension → use Strategy.
• If you have **two** independent changing dimensions → use Bridge.
• If you misuse Bridge on a single‑dimension problem → it merely degrades to Strategy .

三个真实踩坑

Pitfall 一：把实现维度做成静态工具类

A common shortcut is to treat MessageSender

public class SendUtils {
public static void sendByAliyun { ... }
public static void sendByTencent { ... }
}

if ) SendUtils.sendByAliyun;else if ) SendUtils.sendByTencent;

public abstract class Message {
protected MessageSender sender;public void notify {
if {
// 阿里云限流：每秒最多 N 条
rateLimiter.acquire;}
sender.send;说起来，}
}