1. 从两个维度的爆炸说起桥接模式到底在解决什么如果你写过稍微复杂一点的业务代码大概率遇到过这样的场景一个功能模块既要支持多种类型又要在每种类型下支持多种实现方式。比如消息推送消息类型有文本、图片、视频、文件发送渠道有短信、邮件、站内信、推送通知。如果按照最直觉的继承方式去写你需要写 4 × 4 16 个类。每增加一种消息类型就要新增 4 个类每增加一个渠道又要给每种消息类型各加一个子类。类的数量呈乘法级增长这就是所谓的“类爆炸”。桥接模式Bridge Pattern就是专门用来拆解这种乘法关系的。它的核心思路只有一句话把“抽象部分”和“实现部分”分离让它们各自独立变化。听起来有点抽象我用一个更直白的说法——把原来挤在一条继承链上的两个变化维度拆成两条独立的继承链然后用一座“桥”把它们连起来。这座桥是什么在代码层面通常就是一个持有对方引用的成员变量。抽象部分持有一个实现部分的引用调用时把请求委托给实现部分。这样一来抽象部分可以自由扩展子类实现部分也可以自由扩展子类两者互不干扰组合数量从乘法变成了加法。我举个实际项目中的例子。之前做过一个数据导出模块导出格式有 Excel、CSV、PDF数据来源有订单数据、用户数据、财务数据。最初用继承写类名长到离谱比如OrderExcelExporter、UserCsvExporter、FinancePdfExporter……后来重构时改成桥接模式格式是一条继承链数据源是另一条继承链导出器持有一个数据源引用。新增一种格式只需要加一个类新增一种数据源也只需要加一个类。代码量直接砍掉一大半维护起来也清爽得多。桥接模式适合谁看如果你正在被多层继承搞得头晕或者你的类数量随着功能维度增加而失控又或者你在阅读框架源码时经常看到“抽象类持有另一个抽象类引用”这种结构那这篇内容就是为你准备的。我会从设计动机、结构拆解、代码实现、实际踩坑几个角度把桥接模式讲透让你不仅知道怎么用更知道什么时候该用、什么时候不该用。2. 拆开桥接模式的结构四个角色各司其职2.1 Abstraction 与 Implementor 的分工逻辑桥接模式的标准结构里有四个角色但真正核心的只有两个抽象化角色Abstraction和实现化角色Implementor。很多人第一次学的时候会困惑这两个词听起来差不多到底有什么区别我的理解是这样的抽象化角色代表“高层控制逻辑”它关心的是“做什么”实现化角色代表“底层具体实现”它关心的是“怎么做”。举个例子遥控器是抽象化角色它负责接收用户按键、决定发什么指令电视机是实现化角色它负责真正执行开机、换台、调音量这些操作。遥控器不需要知道电视内部是怎么工作的它只需要通过一个接口把指令传过去。在代码里Abstraction 通常是一个抽象类里面持有一个 Implementor 类型的引用。它的方法会调用 Implementor 的方法来完成实际工作。Implementor 是一个接口或抽象类定义了实现部分必须提供的操作。这两个角色各自可以有多个子类分别沿着自己的维度扩展。这里有个关键点Abstraction 持有的引用类型是 Implementor而不是某个具体实现类。这就是“桥”的本质——面向接口编程而不是面向实现编程。正因为持有的是接口所以运行时可以动态替换不同的实现也可以在编译时自由组合不同的抽象子类和实现子类。2.2 RefinedAbstraction 与 ConcreteImplementor 的扩展方式修正抽象化角色RefinedAbstraction是 Abstraction 的子类它扩展或修改了抽象部分的逻辑。比如基础遥控器只能开关和换台高级遥控器增加了语音控制、定时录制等功能。这些新功能属于“高层控制逻辑”的范畴所以放在 RefinedAbstraction 里。具体实现化角色ConcreteImplementor是 Implementor 的子类它提供了具体的底层实现。比如小米电视的实现、索尼电视的实现、投影仪的实现它们都实现了相同的接口但内部逻辑完全不同。这两条继承链是正交的互不影响。RefinedAbstraction 不需要知道具体用的是哪个 ConcreteImplementorConcreteImplementor 也不需要知道被哪个 RefinedAbstraction 调用。它们通过 Implementor 接口进行通信耦合度非常低。我用一个表格来对比这四个角色的职责方便你快速理清角色职责变化方向典型示例Abstraction定义高层控制逻辑持有 Implementor 引用抽象维度扩展基础遥控器RefinedAbstraction扩展抽象逻辑增加新功能抽象维度扩展高级遥控器Implementor定义实现接口声明底层操作实现维度扩展电视接口ConcreteImplementor实现具体底层逻辑实现维度扩展某品牌电视这张表建议你多看几遍因为很多人在实际写代码时容易把逻辑放错位置。比如把“换台”的具体实现写在 Abstraction 里那就失去了桥接的意义。判断标准很简单如果这段逻辑和具体设备强相关就放 Implementor如果这段逻辑是通用的控制流程就放 Abstraction。2.3 桥接模式与策略模式的区别别搞混了经常有人把桥接模式和策略模式搞混因为两者都涉及“持有接口引用”和“委托调用”。我刚开始学的时候也迷糊过后来总结出一个简单的区分方法策略模式只有一个变化维度桥接模式有两个变化维度。策略模式解决的是“算法可以互换”的问题比如排序算法有冒泡、快排、归并运行时选一种。它只有一个维度的变化——算法本身。桥接模式解决的是“抽象和实现各自独立变化”的问题它有两个维度比如“消息类型”和“发送渠道”可以各自扩展。从结构上看策略模式的 Context 持有 Strategy 引用Context 本身通常不继承桥接模式的 Abstraction 持有 Implementor 引用而且 Abstraction 本身还可以有子类。这是最明显的结构差异。还有一个区别是设计意图。策略模式关注的是“如何让算法独立于使用它的客户端变化”桥接模式关注的是“如何让抽象和实现分离避免类爆炸”。当你发现需要两个维度的扩展时选桥接只需要一个维度的替换时选策略。3. 手写一个桥接模式从消息推送到跨平台渲染3.1 场景选择为什么用消息推送来演示我选消息推送作为演示场景因为它足够贴近实际业务而且天然有两个变化维度。消息类型有文本、图片、视频发送渠道有短信、邮件、站内信。如果用继承写3 种消息 × 3 种渠道 9 个类如果再加一种消息类型就变成 12 个类。这种增长方式显然不可持续。用桥接模式重构后消息类型是一条继承链发送渠道是另一条继承链消息类持有一个发送渠道的引用。新增消息类型只需要加一个类新增渠道也只需要加一个类。组合数量从乘法变成加法代码结构清晰很多。这个场景还有一个好处它足够简单不需要复杂的领域知识就能理解。你可以把注意力集中在桥接模式的结构上而不是被业务逻辑分散精力。3.2 代码实现抽象消息与发送渠道的桥接先定义实现化角色——发送渠道接口public interface MessageSender { void send(String content, String recipient); }这个接口只声明了一个send方法参数是消息内容和接收者。所有具体渠道都实现这个接口。然后是具体实现化角色——短信、邮件、站内信public class SmsSender implements MessageSender { Override public void send(String content, String recipient) { System.out.println(通过短信发送给 recipient content); } } public class EmailSender implements MessageSender { Override public void send(String content, String recipient) { System.out.println(通过邮件发送给 recipient content); } } public class InAppSender implements MessageSender { Override public void send(String content, String recipient) { System.out.println(通过站内信发送给 recipient content); } }接下来是抽象化角色——消息基类public abstract class Message { protected MessageSender sender; public Message(MessageSender sender) { this.sender sender; } public abstract void sendMessage(String recipient); }注意这里的关键Message持有一个MessageSender引用但它是抽象类具体的消息内容由子类决定。构造函数注入 sender这样运行时可以灵活替换渠道。然后是修正抽象化角色——文本消息、图片消息、视频消息public class TextMessage extends Message { private String text; public TextMessage(MessageSender sender, String text) { super(sender); this.text text; } Override public void sendMessage(String recipient) { sender.send([文本] text, recipient); } } public class ImageMessage extends Message { private String imageUrl; public ImageMessage(MessageSender sender, String imageUrl) { super(sender); this.imageUrl imageUrl; } Override public void sendMessage(String recipient) { sender.send([图片] imageUrl, recipient); } } public class VideoMessage extends Message { private String videoUrl; public VideoMessage(MessageSender sender, String videoUrl) { super(sender); this.videoUrl videoUrl; } Override public void sendMessage(String recipient) { sender.send([视频] videoUrl, recipient); } }客户端调用时可以自由组合消息类型和发送渠道public class Client { public static void main(String[] args) { Message textViaSms new TextMessage(new SmsSender(), 您的验证码是 1234); textViaSms.sendMessage(13800000000); Message imageViaEmail new ImageMessage(new EmailSender(), https://example.com/pic.png); imageViaEmail.sendMessage(userexample.com); Message videoViaInApp new VideoMessage(new InAppSender(), https://example.com/video.mp4); videoViaInApp.sendMessage(user123); } }运行结果会分别通过短信、邮件、站内信发送对应内容。如果你现在要新增一个“文件消息”只需要继承Message写一个FileMessage类如果要新增“推送通知”渠道只需要实现MessageSender写一个PushSender类。两条继承链完全独立互不影响。3.3 跨平台渲染场景的桥接改造消息推送是业务层面的例子我再举一个更偏底层的场景——跨平台图形渲染。假设你要开发一个绘图库需要支持 Windows、macOS、Linux 三个平台同时要支持圆形、矩形、三角形三种图形。如果用继承你需要写 3 × 3 9 个类。用桥接模式图形是一条继承链平台是另一条继承链。实现化角色是平台接口public interface Platform { void drawCircle(double x, double y, double radius); void drawRectangle(double x, double y, double width, double height); }具体实现化角色是各平台的实现public class WindowsPlatform implements Platform { Override public void drawCircle(double x, double y, double radius) { System.out.println(Windows 绘制圆形中心( x , y )半径 radius); } Override public void drawRectangle(double x, double y, double width, double height) { System.out.println(Windows 绘制矩形左上( x , y )宽 width 高 height); } } public class MacPlatform implements Platform { Override public void drawCircle(double x, double y, double radius) { System.out.println(macOS 绘制圆形中心( x , y )半径 radius); } Override public void drawRectangle(double x, double y, double width, double height) { System.out.println(macOS 绘制矩形左上( x , y )宽 width 高 height); } }抽象化角色是图形基类public abstract class Shape { protected Platform platform; public Shape(Platform platform) { this.platform platform; } public abstract void draw(); }修正抽象化角色是具体图形public class Circle extends Shape { private double x, y, radius; public Circle(Platform platform, double x, double y, double radius) { super(platform); this.x x; this.y y; this.radius radius; } Override public void draw() { platform.drawCircle(x, y, radius); } } public class Rectangle extends Shape { private double x, y, width, height; public Rectangle(Platform platform, double x, double y, double width, double height) { super(platform); this.x x; this.y y; this.width width; this.height height; } Override public void draw() { platform.drawRectangle(x, y, width, height); } }客户端可以自由组合public class DrawingApp { public static void main(String[] args) { Shape circleOnWindows new Circle(new WindowsPlatform(), 100, 100, 50); circleOnWindows.draw(); Shape rectOnMac new Rectangle(new MacPlatform(), 200, 200, 150, 80); rectOnMac.draw(); } }这个例子的好处是它展示了桥接模式在底层系统开发中的价值。图形和平台是两个完全独立的维度桥接模式让它们可以各自演化。新增一种图形不需要改平台代码新增一个平台也不需要改图形代码。4. 桥接模式在实际项目中的取舍与踩坑记录4.1 什么时候该用桥接什么时候不该用桥接模式不是银弹用错了反而增加复杂度。我总结了几条判断标准供你参考。该用桥接的信号第一你发现类的数量随着功能维度增加而呈乘法增长比如 3 种类型 × 4 种渠道 12 个类。第二你有两个或以上的变化维度而且它们需要独立扩展。第三你希望在运行时动态切换实现而不是在编译时固定。第四你在阅读框架源码时看到“抽象类持有另一个抽象类引用”的结构想理解其设计意图。不该用桥接的信号第一只有一个变化维度用策略模式就够了。第二两个维度的变化频率都很低用继承也不会导致类爆炸。第三团队对设计模式不熟悉引入桥接反而增加理解成本。第四性能敏感场景桥接模式多了一层委托调用虽然开销很小但在极端情况下需要考虑。我之前在一个小项目里过度使用了桥接模式本来只有两种类型和两种渠道总共四个类就能搞定结果拆成两条继承链后反而多了好几个文件。后来复盘时发现当维度数量少且稳定时直接继承更简单直接。桥接模式的价值在于应对变化如果变化本身就不存在那桥接就是多余的。4.2 桥接模式与依赖注入的配合方式在实际项目中桥接模式的 Implementor 通常不会在构造函数里直接 new而是通过依赖注入容器来管理。这样做的好处是实现类的创建和生命周期交给容器Abstraction 只关心接口调用。以 Spring 为例你可以把 MessageSender 的各个实现注册为 Bean然后在 Message 的子类中通过构造函数注入。如果需要在运行时动态选择渠道可以注入一个 Map 或者使用工厂模式来获取对应的 Sender。这里有个坑需要注意如果 Abstraction 是单例 Bean而 Implementor 需要根据请求动态变化那就不能在构造函数里固定注入。解决方案是把 Implementor 作为方法参数传入或者使用 ThreadLocal 来保存当前请求的 Implementor。我踩过这个坑当时一个导出服务被设计成单例但导出格式需要根据用户选择动态变化结果所有请求都用了同一个格式。后来改成方法参数传入才解决。4.3 常见误用把桥接写成策略的几种典型情况第一种误用是 Abstraction 没有子类。如果 Abstraction 只有一个具体类那它和策略模式的 Context 就没有区别了。桥接模式的核心价值在于抽象部分也可以扩展如果抽象部分不扩展那就退化成策略模式了。第二种误用是把两个维度合并到一个继承链里。比如有人写了一个MessageSender接口然后让TextMessage直接实现这个接口而不是持有引用。这样虽然也能工作但失去了桥接的灵活性——消息类型和发送渠道又耦合在一起了。第三种误用是 Implementor 接口设计得太窄或太宽。太窄会导致 Abstraction 需要做很多额外工作太宽会导致实现类需要实现很多不需要的方法。我的经验是Implementor 接口应该只包含“底层操作”也就是那些和具体实现强相关的方法。高层控制逻辑应该留在 Abstraction 里。4.4 桥接模式在框架源码中的真实身影很多主流框架都用了桥接模式只是你可能没注意到。比如 JDBC 的驱动管理DriverManager是抽象部分各个数据库厂商的Driver是实现部分。DriverManager不关心具体是 MySQL 还是 PostgreSQL它只通过Driver接口来获取连接。新增一种数据库只需要提供一个Driver实现不需要改DriverManager的代码。再比如日志框架Logger是抽象部分Appender是实现部分。日志级别和输出目标控制台、文件、远程是两个独立变化的维度。你可以用桥接模式来理解这种结构虽然框架本身可能没有明确说“我用了桥接模式”。阅读源码时如果你看到“抽象类持有另一个抽象类或接口的引用并且通过构造函数注入”那大概率就是桥接模式或者它的变体。理解了这个结构你就能更快地把握框架的设计意图。5. 从桥接模式延伸出去的设计思考桥接模式的本质是“分离变化维度”这个思想可以应用到很多地方。比如前端开发中组件的“外观”和“行为”可以分离游戏开发中角色的“属性”和“技能”可以分离数据处理中“数据源”和“处理逻辑”可以分离。我个人的体会是当你发现代码里有两个维度的变化纠缠在一起时就应该考虑桥接模式。判断标准很简单如果你画一张二维表格横轴是一个维度纵轴是另一个维度每个交叉点都需要一个类那就是桥接模式的典型场景。还有一个延伸思考是组合优于继承的原则。桥接模式本质上是用组合替代了多层继承。它把“是一个”的关系变成了“有一个”的关系从而获得了更大的灵活性。这个思路在很多时候都适用——当你发现继承层次太深时不妨想想能不能用组合来拆解。最后分享一个我在实际项目中的小技巧当你拿不准该不该用桥接模式时先用继承写一版看看类的数量会不会失控。如果类数量在可接受范围内那就用继承如果发现每加一个功能就要加一堆类那就果断重构为桥接。设计模式是工具不是目的能解决问题的模式才是好模式。 
长河君 · 2026/10/16 5:11:56 · 阅读 1.2k 桥接模式详解：分离变化维度，解决类爆炸问题
1. 从两个维度的爆炸说起桥接模式到底在解决什么如果你写过稍微复杂一点的业务代码大概率遇到过这样的场景一个功能模块既要支持多种类型又要在每种类型下支持多种实现方式。比如消息推送消息类型有文本、图片、视频、文件发送渠道有短信、邮件、站内信、推送通知。如果按照最直觉的继承方式去写你需要写 4 × 4 16 个类。每增加一种消息类型就要新增 4 个类每增加一个渠道又要给每种消息类型各加一个子类。类的数量呈乘法级增长这就是所谓的“类爆炸”。桥接模式Bridge Pattern就是专门用来拆解这种乘法关系的。它的核心思路只有一句话把“抽象部分”和“实现部分”分离让它们各自独立变化。听起来有点抽象我用一个更直白的说法——把原来挤在一条继承链上的两个变化维度拆成两条独立的继承链然后用一座“桥”把它们连起来。这座桥是什么在代码层面通常就是一个持有对方引用的成员变量。抽象部分持有一个实现部分的引用调用时把请求委托给实现部分。这样一来抽象部分可以自由扩展子类实现部分也可以自由扩展子类两者互不干扰组合数量从乘法变成了加法。我举个实际项目中的例子。之前做过一个数据导出模块导出格式有 Excel、CSV、PDF数据来源有订单数据、用户数据、财务数据。最初用继承写类名长到离谱比如OrderExcelExporter、UserCsvExporter、FinancePdfExporter……后来重构时改成桥接模式格式是一条继承链数据源是另一条继承链导出器持有一个数据源引用。新增一种格式只需要加一个类新增一种数据源也只需要加一个类。代码量直接砍掉一大半维护起来也清爽得多。桥接模式适合谁看如果你正在被多层继承搞得头晕或者你的类数量随着功能维度增加而失控又或者你在阅读框架源码时经常看到“抽象类持有另一个抽象类引用”这种结构那这篇内容就是为你准备的。我会从设计动机、结构拆解、代码实现、实际踩坑几个角度把桥接模式讲透让你不仅知道怎么用更知道什么时候该用、什么时候不该用。2. 拆开桥接模式的结构四个角色各司其职2.1 Abstraction 与 Implementor 的分工逻辑桥接模式的标准结构里有四个角色但真正核心的只有两个抽象化角色Abstraction和实现化角色Implementor。很多人第一次学的时候会困惑这两个词听起来差不多到底有什么区别我的理解是这样的抽象化角色代表“高层控制逻辑”它关心的是“做什么”实现化角色代表“底层具体实现”它关心的是“怎么做”。举个例子遥控器是抽象化角色它负责接收用户按键、决定发什么指令电视机是实现化角色它负责真正执行开机、换台、调音量这些操作。遥控器不需要知道电视内部是怎么工作的它只需要通过一个接口把指令传过去。在代码里Abstraction 通常是一个抽象类里面持有一个 Implementor 类型的引用。它的方法会调用 Implementor 的方法来完成实际工作。Implementor 是一个接口或抽象类定义了实现部分必须提供的操作。这两个角色各自可以有多个子类分别沿着自己的维度扩展。这里有个关键点Abstraction 持有的引用类型是 Implementor而不是某个具体实现类。这就是“桥”的本质——面向接口编程而不是面向实现编程。正因为持有的是接口所以运行时可以动态替换不同的实现也可以在编译时自由组合不同的抽象子类和实现子类。2.2 RefinedAbstraction 与 ConcreteImplementor 的扩展方式修正抽象化角色RefinedAbstraction是 Abstraction 的子类它扩展或修改了抽象部分的逻辑。比如基础遥控器只能开关和换台高级遥控器增加了语音控制、定时录制等功能。这些新功能属于“高层控制逻辑”的范畴所以放在 RefinedAbstraction 里。具体实现化角色ConcreteImplementor是 Implementor 的子类它提供了具体的底层实现。比如小米电视的实现、索尼电视的实现、投影仪的实现它们都实现了相同的接口但内部逻辑完全不同。这两条继承链是正交的互不影响。RefinedAbstraction 不需要知道具体用的是哪个 ConcreteImplementorConcreteImplementor 也不需要知道被哪个 RefinedAbstraction 调用。它们通过 Implementor 接口进行通信耦合度非常低。我用一个表格来对比这四个角色的职责方便你快速理清角色职责变化方向典型示例Abstraction定义高层控制逻辑持有 Implementor 引用抽象维度扩展基础遥控器RefinedAbstraction扩展抽象逻辑增加新功能抽象维度扩展高级遥控器Implementor定义实现接口声明底层操作实现维度扩展电视接口ConcreteImplementor实现具体底层逻辑实现维度扩展某品牌电视这张表建议你多看几遍因为很多人在实际写代码时容易把逻辑放错位置。比如把“换台”的具体实现写在 Abstraction 里那就失去了桥接的意义。判断标准很简单如果这段逻辑和具体设备强相关就放 Implementor如果这段逻辑是通用的控制流程就放 Abstraction。2.3 桥接模式与策略模式的区别别搞混了经常有人把桥接模式和策略模式搞混因为两者都涉及“持有接口引用”和“委托调用”。我刚开始学的时候也迷糊过后来总结出一个简单的区分方法策略模式只有一个变化维度桥接模式有两个变化维度。策略模式解决的是“算法可以互换”的问题比如排序算法有冒泡、快排、归并运行时选一种。它只有一个维度的变化——算法本身。桥接模式解决的是“抽象和实现各自独立变化”的问题它有两个维度比如“消息类型”和“发送渠道”可以各自扩展。从结构上看策略模式的 Context 持有 Strategy 引用Context 本身通常不继承桥接模式的 Abstraction 持有 Implementor 引用而且 Abstraction 本身还可以有子类。这是最明显的结构差异。还有一个区别是设计意图。策略模式关注的是“如何让算法独立于使用它的客户端变化”桥接模式关注的是“如何让抽象和实现分离避免类爆炸”。当你发现需要两个维度的扩展时选桥接只需要一个维度的替换时选策略。3. 手写一个桥接模式从消息推送到跨平台渲染3.1 场景选择为什么用消息推送来演示我选消息推送作为演示场景因为它足够贴近实际业务而且天然有两个变化维度。消息类型有文本、图片、视频发送渠道有短信、邮件、站内信。如果用继承写3 种消息 × 3 种渠道 9 个类如果再加一种消息类型就变成 12 个类。这种增长方式显然不可持续。用桥接模式重构后消息类型是一条继承链发送渠道是另一条继承链消息类持有一个发送渠道的引用。新增消息类型只需要加一个类新增渠道也只需要加一个类。组合数量从乘法变成加法代码结构清晰很多。这个场景还有一个好处它足够简单不需要复杂的领域知识就能理解。你可以把注意力集中在桥接模式的结构上而不是被业务逻辑分散精力。3.2 代码实现抽象消息与发送渠道的桥接先定义实现化角色——发送渠道接口public interface MessageSender { void send(String content, String recipient); }这个接口只声明了一个send方法参数是消息内容和接收者。所有具体渠道都实现这个接口。然后是具体实现化角色——短信、邮件、站内信public class SmsSender implements MessageSender { Override public void send(String content, String recipient) { System.out.println(通过短信发送给 recipient content); } } public class EmailSender implements MessageSender { Override public void send(String content, String recipient) { System.out.println(通过邮件发送给 recipient content); } } public class InAppSender implements MessageSender { Override public void send(String content, String recipient) { System.out.println(通过站内信发送给 recipient content); } }接下来是抽象化角色——消息基类public abstract class Message { protected MessageSender sender; public Message(MessageSender sender) { this.sender sender; } public abstract void sendMessage(String recipient); }注意这里的关键Message持有一个MessageSender引用但它是抽象类具体的消息内容由子类决定。构造函数注入 sender这样运行时可以灵活替换渠道。然后是修正抽象化角色——文本消息、图片消息、视频消息public class TextMessage extends Message { private String text; public TextMessage(MessageSender sender, String text) { super(sender); this.text text; } Override public void sendMessage(String recipient) { sender.send([文本] text, recipient); } } public class ImageMessage extends Message { private String imageUrl; public ImageMessage(MessageSender sender, String imageUrl) { super(sender); this.imageUrl imageUrl; } Override public void sendMessage(String recipient) { sender.send([图片] imageUrl, recipient); } } public class VideoMessage extends Message { private String videoUrl; public VideoMessage(MessageSender sender, String videoUrl) { super(sender); this.videoUrl videoUrl; } Override public void sendMessage(String recipient) { sender.send([视频] videoUrl, recipient); } }客户端调用时可以自由组合消息类型和发送渠道public class Client { public static void main(String[] args) { Message textViaSms new TextMessage(new SmsSender(), 您的验证码是 1234); textViaSms.sendMessage(13800000000); Message imageViaEmail new ImageMessage(new EmailSender(), https://example.com/pic.png); imageViaEmail.sendMessage(userexample.com); Message videoViaInApp new VideoMessage(new InAppSender(), https://example.com/video.mp4); videoViaInApp.sendMessage(user123); } }运行结果会分别通过短信、邮件、站内信发送对应内容。如果你现在要新增一个“文件消息”只需要继承Message写一个FileMessage类如果要新增“推送通知”渠道只需要实现MessageSender写一个PushSender类。两条继承链完全独立互不影响。3.3 跨平台渲染场景的桥接改造消息推送是业务层面的例子我再举一个更偏底层的场景——跨平台图形渲染。假设你要开发一个绘图库需要支持 Windows、macOS、Linux 三个平台同时要支持圆形、矩形、三角形三种图形。如果用继承你需要写 3 × 3 9 个类。用桥接模式图形是一条继承链平台是另一条继承链。实现化角色是平台接口public interface Platform { void drawCircle(double x, double y, double radius); void drawRectangle(double x, double y, double width, double height); }具体实现化角色是各平台的实现public class WindowsPlatform implements Platform { Override public void drawCircle(double x, double y, double radius) { System.out.println(Windows 绘制圆形中心( x , y )半径 radius); } Override public void drawRectangle(double x, double y, double width, double height) { System.out.println(Windows 绘制矩形左上( x , y )宽 width 高 height); } } public class MacPlatform implements Platform { Override public void drawCircle(double x, double y, double radius) { System.out.println(macOS 绘制圆形中心( x , y )半径 radius); } Override public void drawRectangle(double x, double y, double width, double height) { System.out.println(macOS 绘制矩形左上( x , y )宽 width 高 height); } }抽象化角色是图形基类public abstract class Shape { protected Platform platform; public Shape(Platform platform) { this.platform platform; } public abstract void draw(); }修正抽象化角色是具体图形public class Circle extends Shape { private double x, y, radius; public Circle(Platform platform, double x, double y, double radius) { super(platform); this.x x; this.y y; this.radius radius; } Override public void draw() { platform.drawCircle(x, y, radius); } } public class Rectangle extends Shape { private double x, y, width, height; public Rectangle(Platform platform, double x, double y, double width, double height) { super(platform); this.x x; this.y y; this.width width; this.height height; } Override public void draw() { platform.drawRectangle(x, y, width, height); } }客户端可以自由组合public class DrawingApp { public static void main(String[] args) { Shape circleOnWindows new Circle(new WindowsPlatform(), 100, 100, 50); circleOnWindows.draw(); Shape rectOnMac new Rectangle(new MacPlatform(), 200, 200, 150, 80); rectOnMac.draw(); } }这个例子的好处是它展示了桥接模式在底层系统开发中的价值。图形和平台是两个完全独立的维度桥接模式让它们可以各自演化。新增一种图形不需要改平台代码新增一个平台也不需要改图形代码。4. 桥接模式在实际项目中的取舍与踩坑记录4.1 什么时候该用桥接什么时候不该用桥接模式不是银弹用错了反而增加复杂度。我总结了几条判断标准供你参考。该用桥接的信号第一你发现类的数量随着功能维度增加而呈乘法增长比如 3 种类型 × 4 种渠道 12 个类。第二你有两个或以上的变化维度而且它们需要独立扩展。第三你希望在运行时动态切换实现而不是在编译时固定。第四你在阅读框架源码时看到“抽象类持有另一个抽象类引用”的结构想理解其设计意图。不该用桥接的信号第一只有一个变化维度用策略模式就够了。第二两个维度的变化频率都很低用继承也不会导致类爆炸。第三团队对设计模式不熟悉引入桥接反而增加理解成本。第四性能敏感场景桥接模式多了一层委托调用虽然开销很小但在极端情况下需要考虑。我之前在一个小项目里过度使用了桥接模式本来只有两种类型和两种渠道总共四个类就能搞定结果拆成两条继承链后反而多了好几个文件。后来复盘时发现当维度数量少且稳定时直接继承更简单直接。桥接模式的价值在于应对变化如果变化本身就不存在那桥接就是多余的。4.2 桥接模式与依赖注入的配合方式在实际项目中桥接模式的 Implementor 通常不会在构造函数里直接 new而是通过依赖注入容器来管理。这样做的好处是实现类的创建和生命周期交给容器Abstraction 只关心接口调用。以 Spring 为例你可以把 MessageSender 的各个实现注册为 Bean然后在 Message 的子类中通过构造函数注入。如果需要在运行时动态选择渠道可以注入一个 Map 或者使用工厂模式来获取对应的 Sender。这里有个坑需要注意如果 Abstraction 是单例 Bean而 Implementor 需要根据请求动态变化那就不能在构造函数里固定注入。解决方案是把 Implementor 作为方法参数传入或者使用 ThreadLocal 来保存当前请求的 Implementor。我踩过这个坑当时一个导出服务被设计成单例但导出格式需要根据用户选择动态变化结果所有请求都用了同一个格式。后来改成方法参数传入才解决。4.3 常见误用把桥接写成策略的几种典型情况第一种误用是 Abstraction 没有子类。如果 Abstraction 只有一个具体类那它和策略模式的 Context 就没有区别了。桥接模式的核心价值在于抽象部分也可以扩展如果抽象部分不扩展那就退化成策略模式了。第二种误用是把两个维度合并到一个继承链里。比如有人写了一个MessageSender接口然后让TextMessage直接实现这个接口而不是持有引用。这样虽然也能工作但失去了桥接的灵活性——消息类型和发送渠道又耦合在一起了。第三种误用是 Implementor 接口设计得太窄或太宽。太窄会导致 Abstraction 需要做很多额外工作太宽会导致实现类需要实现很多不需要的方法。我的经验是Implementor 接口应该只包含“底层操作”也就是那些和具体实现强相关的方法。高层控制逻辑应该留在 Abstraction 里。4.4 桥接模式在框架源码中的真实身影很多主流框架都用了桥接模式只是你可能没注意到。比如 JDBC 的驱动管理DriverManager是抽象部分各个数据库厂商的Driver是实现部分。DriverManager不关心具体是 MySQL 还是 PostgreSQL它只通过Driver接口来获取连接。新增一种数据库只需要提供一个Driver实现不需要改DriverManager的代码。再比如日志框架Logger是抽象部分Appender是实现部分。日志级别和输出目标控制台、文件、远程是两个独立变化的维度。你可以用桥接模式来理解这种结构虽然框架本身可能没有明确说“我用了桥接模式”。阅读源码时如果你看到“抽象类持有另一个抽象类或接口的引用并且通过构造函数注入”那大概率就是桥接模式或者它的变体。理解了这个结构你就能更快地把握框架的设计意图。5. 从桥接模式延伸出去的设计思考桥接模式的本质是“分离变化维度”这个思想可以应用到很多地方。比如前端开发中组件的“外观”和“行为”可以分离游戏开发中角色的“属性”和“技能”可以分离数据处理中“数据源”和“处理逻辑”可以分离。我个人的体会是当你发现代码里有两个维度的变化纠缠在一起时就应该考虑桥接模式。判断标准很简单如果你画一张二维表格横轴是一个维度纵轴是另一个维度每个交叉点都需要一个类那就是桥接模式的典型场景。还有一个延伸思考是组合优于继承的原则。桥接模式本质上是用组合替代了多层继承。它把“是一个”的关系变成了“有一个”的关系从而获得了更大的灵活性。这个思路在很多时候都适用——当你发现继承层次太深时不妨想想能不能用组合来拆解。最后分享一个我在实际项目中的小技巧当你拿不准该不该用桥接模式时先用继承写一版看看类的数量会不会失控。如果类数量在可接受范围内那就用继承如果发现每加一个功能就要加一堆类那就果断重构为桥接。设计模式是工具不是目的能解决问题的模式才是好模式。