桥接模式名字玄,实际解决的问题非常具体:当一个东西在两个维度上各自演化时,不要用继承把它们硬绑在一起。最经典的例子是图形 × 颜色:有 Shape(圆、方、三角)和 Color(红、绿、蓝)两个维度,朴素的继承会爆出 3×3=9 个类(红圆、绿圆、蓝圆、红方……),桥接模式让你只需要 3+3=6 个类。这篇文章把桥接的本质讲透,带你看 JDBC、SLF4J、跨平台 UI 是怎么用它的。
问题:继承的笛卡尔积爆炸
// 朴素继承
class Shape {}
class Circle extends Shape {}
class Square extends Shape {}
class Triangle extends Shape {}
// 加颜色需求
class RedCircle extends Circle {}
class GreenCircle extends Circle {}
class BlueCircle extends Circle {}
class RedSquare extends Square {}
class GreenSquare extends Square {}
class BlueSquare extends Square {}
// ... 9 个类
// 再加"填充模式"(实心 / 空心 / 渐变)? 9 × 3 = 27 个类
// 再加"线条样式"(实线 / 虚线 / 点状)? 27 × 3 = 81 个类每加一个维度,类数量乘起来。这就是"组合爆炸"。维护这种代码是噩梦 —— 改一个颜色行为要改 9 个类。
桥接模式说:把"两个独立变化的维度"分成两个独立的层次,然后用组合把它们连起来。
桥接的标准结构
// 维度 1:Shape(抽象层 / Abstraction)
abstract class Shape {
protected Color color; // 桥! 持有另一维度的引用
public Shape(Color color) { this.color = color; }
public abstract void draw();
}
class Circle extends Shape {
public Circle(Color color) { super(color); }
public void draw() {
System.out.println("Circle with " + color.fill());
}
}
class Square extends Shape {
public Square(Color color) { super(color); }
public void draw() {
System.out.println("Square with " + color.fill());
}
}
// 维度 2:Color(实现层 / Implementation)
interface Color {
String fill();
}
class Red implements Color { public String fill() { return "red"; } }
class Green implements Color { public String fill() { return "green"; } }
class Blue implements Color { public String fill() { return "blue"; } }
// 客户端:任意组合
new Circle(new Red()).draw(); // Circle with red
new Square(new Green()).draw(); // Square with green从 N×M 个类降到 N+M 个类。新加一种形状,只需要加一个 Shape 子类,所有颜色自动可用;新加一种颜色,只需要加一个 Color 实现,所有形状自动支持。
关键认知:抽象与实现的解耦
GoF 原文说桥接的目的是"将抽象部分与它的实现部分分离,使它们都可以独立地变化"。这里"抽象"和"实现"不是面向对象意义上的抽象类 vs 实现类,而是"高层定义" vs "底层细节":
- 抽象层:Shape(在画什么 / 高层概念)。
- 实现层:Color / Renderer(怎么画 / 底层细节)。
桥接让两层各自演化:加更多形状不影响绘制后端,加更多绘制后端不影响形状种类。
实战 1:JDBC
JDBC 是桥接模式在 Java 标准库的代表。一边是抽象层:你写的 Java 代码,用 Connection / Statement / ResultSet 这些接口;另一边是实现层:各厂商的 JDBC 驱动(MySQL Connector/J、PostgreSQL JDBC、Oracle thin driver)。
Class.forName("com.mysql.cj.jdbc.Driver"); // 选哪个实现
Connection conn = DriverManager.getConnection("jdbc:mysql://...");
// 业务代码完全不知道是 MySQL 还是别的
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?");
stmt.setLong(1, 123);
ResultSet rs = stmt.executeQuery();切到 PostgreSQL 只需换驱动 + URL,业务代码一行不改。这正是桥接的承诺:抽象侧(SQL API)和实现侧(驱动)各自演进 —— 新版 JDBC 标准出来时,你只需要等驱动跟进;新数据库出现时,提供 JDBC 驱动即可接入。
实战 2:跨平台 GUI 库
看 Java AWT 的设计:抽象层是 Button / TextField / Frame 这些逻辑控件,实现层是 ButtonPeer / TextFieldPeer 这些平台原生 peer。
// 抽象层(平台无关)
abstract class Component {
protected ComponentPeer peer; // 桥!
public void setBackground(Color c) { peer.setBackground(c); }
}
class Button extends Component {
public Button() { peer = Toolkit.getDefaultToolkit().createButton(this); }
public void setLabel(String s) { ((ButtonPeer) peer).setLabel(s); }
}
// 实现层(平台相关,Windows / Mac / X11 各一份)
interface ButtonPeer extends ComponentPeer {
void setLabel(String label);
// ...
}
class WindowsButtonPeer implements ButtonPeer { /* 调 Win32 API */ }
class XButtonPeer implements ButtonPeer { /* 调 X11 API */ }这就是为什么 AWT 控件能"看上去是平台原生" —— 它把界面逻辑(抽象层)和平台细节(实现层)用桥接彻底分开。Swing 后来抛弃了这种 Peer 模型走轻量化路线,但桥接的思路在其他跨平台框架(Qt、Flutter、React Native)里继续存在。
实战 3:消息推送的通道 × 内容矩阵
真实业务场景:你要发"订单成功"通知,通过"短信 / 邮件 / 站内信 / 推送"四个通道发。如果再加"促销通知""安全告警"等等,内容 × 通道矩阵会爆炸。
// 抽象层:消息类型
abstract class Message {
protected MessageSender sender;
public Message(MessageSender sender) { this.sender = sender; }
public abstract void send(User user);
}
class OrderSuccessMessage extends Message {
private final Order order;
public OrderSuccessMessage(Order o, MessageSender s) { super(s); this.order = o; }
public void send(User user) {
String text = String.format("订单 %s 已支付成功,金额 %s", order.getId(), order.getTotal());
sender.send(user, text);
}
}
class PromotionMessage extends Message {
private final Coupon coupon;
public PromotionMessage(Coupon c, MessageSender s) { super(s); this.coupon = c; }
public void send(User user) {
String text = String.format("您有一张 %s 优惠券,有效期至 %s", coupon.getAmount(), coupon.getExpire());
sender.send(user, text);
}
}
// 实现层:通道
interface MessageSender {
void send(User user, String content);
}
class SmsSender implements MessageSender { /* 调短信网关 */ }
class EmailSender implements MessageSender { /* 调 SMTP */ }
class InAppSender implements MessageSender { /* 写数据库表 */ }
class PushSender implements MessageSender { /* 调 APNs / FCM */ }
// 客户端任意组合
new OrderSuccessMessage(order, new SmsSender()).send(user);
new PromotionMessage(coupon, new EmailSender()).send(user);
// 想"同时多通道"也很容易 —— 弄个组合 sender
class CompositeSender implements MessageSender {
private final List<MessageSender> senders;
public CompositeSender(MessageSender... ss) { this.senders = Arrays.asList(ss); }
public void send(User user, String content) {
senders.forEach(s -> s.send(user, content));
}
}
new OrderSuccessMessage(order, new CompositeSender(new SmsSender(), new InAppSender())).send(user);这种设计让你能独立扩展:加"系统升级公告"= 新增一个 Message 子类;加"企业微信"通道 = 新增一个 Sender 实现。两个维度完全独立。
桥接 vs 适配器
这两个最容易混淆。区别在于"何时引入"和"为什么":
- 适配器:亡羊补牢。已有的 A 接口和已有的 B 接口对不上,事后用适配器粘合。你没法控制两边的设计。
- 桥接:未雨绸缪。你主动在设计时把两个维度分开,让它们之后能独立演化。你掌控两边的设计。
所以适配器是"修补",桥接是"预判"。判断一段代码该用谁,看你是在"做集成"还是"做架构"。
桥接 vs 策略
结构上桥接(Shape 持有 Color)和策略(Context 持有 Strategy)看起来一模一样 —— 都是组合。区别在于设计意图:
- 策略:同一件事的不同算法(排序的快排/归并/堆排),Context 在不同 Strategy 间切换。
- 桥接:抽象的不同维度(Shape × Color),两个维度都独立成体系。
区分要点:策略侧重"行为可换",桥接侧重"两个维度分别演化"。策略通常只有 Context + Strategy 两个角色,桥接的两边都各有继承结构。
各语言里的桥接
Python:鸭子类型让桥接更轻
class Shape:
def __init__(self, renderer):
self.renderer = renderer # 桥
def draw(self):
raise NotImplementedError
class Circle(Shape):
def __init__(self, renderer, radius):
super().__init__(renderer)
self.radius = radius
def draw(self):
self.renderer.render_circle(self.radius)
# 实现层:不需要显式接口,有 render_circle 方法就行
class SvgRenderer:
def render_circle(self, r): print(f'<circle r="{r}"/>')
class CanvasRenderer:
def render_circle(self, r): print(f'ctx.arc(0,0,{r},0,2*PI)')
Circle(SvgRenderer(), 10).draw()
Circle(CanvasRenderer(), 10).draw()TypeScript:用类型表达双维度
interface Renderer { renderCircle(r: number): void; renderSquare(s: number): void; }
class SvgRenderer implements Renderer { /* ... */ }
class CanvasRenderer implements Renderer { /* ... */ }
abstract class Shape {
constructor(protected renderer: Renderer) {}
abstract draw(): void;
}
class Circle extends Shape {
constructor(renderer: Renderer, private radius: number) { super(renderer); }
draw() { this.renderer.renderCircle(this.radius); }
}
class Square extends Shape {
constructor(renderer: Renderer, private side: number) { super(renderer); }
draw() { this.renderer.renderSquare(this.side); }
}
new Circle(new SvgRenderer(), 10).draw();桥接的代价
1. 一次性引入复杂度
原本一个 Shape 类,现在变成 Shape + Color 两套继承结构 + 组合关系。代码量变多,新开发者第一次看会迷茫。除非真的有两个独立变化维度,否则桥接是过度设计。
2. 跨维度的特殊行为难处理
如果"红色三角"有特殊行为(只有这个组合才会做某件事),桥接的"两个维度独立"假设就破裂了。这时要么把特殊逻辑塞到 Shape 子类里(用 instanceof Color 判断,坏味道),要么承认这个组合"必须有专门的实现类",绕回继承的老路。
3. 两边的接口设计耦合
抽象层调用的方法,实现层都要提供。如果某个新形状需要"圆弧"绘制能力,所有 Renderer 都要新增 renderArc 方法 —— 实现侧被抽象侧的需求"推着"演化。降低耦合的办法是让接口尽量小,但完全独立几乎不可能。
什么时候用桥接
给一个清单,满足越多越该上:
- 有两个明显独立变化的维度(产品 × 平台、消息 × 通道、形状 × 颜色)。
- 两个维度都已经有 3 个以上的变体,或者预期会增长。
- 这两个维度正交(任意组合都合理,而不是某些组合无意义)。
- 你想避免笛卡尔积爆炸的类数量。
如果只是"有两个相关的类",别上桥接,组合就够。设计模式不是越多越好。
常见坑
坑 1:把抽象和实现混淆。 把所有可变的东西都塞到"实现层",抽象层退化成一个空壳;或者反过来,抽象层定义了过多逻辑,实现层只是个数据载体。正确做法是两边都有自己的合理职责:抽象层组织业务流程,实现层处理具体细节。
坑 2:实现层接口设计不当。 接口太大,导致每个实现都要写一大堆"用不到但要实现"的方法;接口太小,抽象层要做的事覆盖不到,只能在抽象层硬塞条件分支。划分接口的标准:让实现层的接口"足够通用以支持所有抽象层需求,且每个方法都被多数实现真正用到"。
坑 3:用桥接代替策略。 只有一个维度变化的场景上桥接是过度设计 —— 策略就够。识别标志:两边的继承结构哪边是"主"哪边是"辅"?分得清主次的多半是策略,分不清的才是桥接。
写在最后
桥接模式不是最常用的设计模式,但当问题对路时它的威力极大 —— 把 N×M 的类爆炸压成 N+M。它的核心思想"组合优于继承"贯穿整个面向对象现代实践,不只是这一个模式。理解了桥接,你也理解了为什么 Spring 用依赖注入而不是模板方法,为什么 Java 集合框架用 Comparator 接口而不是让每个类自己实现排序。
下次设计一个会"双向演化"的系统时,先停一秒问自己:"这两条变化轴是不是独立的?" 是的话,把它们分开,让组合替你承担维护成本。三五年后回头看,你会感谢当初没有走继承爆炸那条路。
—— 别看了 · 2026