★ FEATURED ARTICLE 1. 桥接模式到底在解决什么问题第一次接触桥接模式的人十有八九会有一种“这不是多此一举吗”的疑惑。我当年也是这么想的。一个功能直接继承不就完了为什么要拆成两个维度还要搞一个“桥”出来直到我在一个真实项目里被继承体系炸得体无完肤才真正理解这个模式的价值。先说结论桥接模式的核心是把“抽象部分”和“实现部分”分离让它们可以各自独立地变化。这句话每个教程都会写但真正理解它需要你踩过一次“类爆炸”的坑。举个我亲身经历的场景。当时做一个跨平台的图形渲染模块需求是这样的支持三种图形圆形、矩形、三角形每种图形要能在两个平台平台A、平台B上绘制。如果用传统继承你需要写 3 × 2 6 个类平台A圆形、平台A矩形、平台A三角形、平台B圆形、平台B矩形、平台B三角形。这还只是两个维度。后来产品说要加一个“椭圆”再加一个“平台C”类数量直接变成 4 × 3 12 个。再后来要加颜色维度……你算算3个维度各3种取值就是27个类。这不是写代码这是在搞排列组合。桥接模式的思路完全不同。它把“图形形状”作为一个抽象层次把“绘制平台”作为另一个抽象层次两者通过组合也就是那座“桥”连接起来。形状维度加一种只加一个形状类平台维度加一种只加一个平台类。类数量从乘法关系变成了加法关系。这就是桥接模式最朴素也最强大的价值。适合谁来深入学这个模式如果你写过超过三层深的继承体系或者你的类名里出现了“XXWithYYAndZZ”这种命名那你就是桥接模式的目标用户。如果你只是写写简单的业务逻辑可能暂时用不上但理解它的思想对代码设计能力的提升是实打实的。注意桥接模式不是用来替代继承的而是用来补充继承的。继承表达的是“is-a”关系桥接表达的是“has-a”关系。用错了场景反而会让代码更复杂。2. 拆解桥接模式的核心结构2.1 四个角色一个都不能少桥接模式的结构看起来简单但每个角色承担的职责非常明确。我用一个实际例子来串讲假设我们要做一个消息推送系统支持两种消息类型普通消息、紧急消息支持两种发送渠道短信、邮件。第一个角色抽象化角色Abstraction。在这个例子里就是“消息”这个抽象类。它持有一个发送渠道的引用也就是那座“桥”。它定义了消息发送的基本流程但具体怎么发它不管交给渠道去处理。第二个角色修正抽象化角色RefinedAbstraction。就是“普通消息”和“紧急消息”。它们继承自“消息”可以对发送流程做自己的定制。比如紧急消息可能在发送前要加一个额外的标记或者发送后要记录日志。第三个角色实现化角色Implementor。就是“发送渠道”这个接口。它定义了“发送”这个方法但不关心消息内容是什么。第四个角色具体实现化角色ConcreteImplementor。就是“短信渠道”和“邮件渠道”。它们负责真正的发送逻辑。这四个角色的关系用一句话概括就是抽象化角色持有实现化角色的引用修正抽象化角色继承抽象化角色具体实现化角色实现实现化角色接口。听起来绕口但画成结构就很清晰了。2.2 为什么是组合而不是继承这是桥接模式最关键的决策点。很多人会问为什么不让“普通消息”直接继承“短信渠道”这样不就不用组合了吗问题在于如果你让消息继承渠道那么“普通消息”和“紧急消息”就绑死在了“短信”上。你想让紧急消息也支持邮件就得再写一个“紧急邮件消息”。每增加一个渠道所有消息类型都要重新写一遍。这就是继承带来的紧耦合。组合的好处是消息和渠道之间是“用”的关系而不是“是”的关系。一条消息可以用短信发也可以用邮件发甚至可以在运行时动态切换。这种灵活性是继承给不了的。我个人的经验是当你发现一个类有两个或以上的独立变化维度时就应该考虑桥接模式。注意关键词是“独立变化”。如果两个维度是联动的比如A变了B必须跟着变那桥接模式就不合适可能用其他模式更恰当。2.3 桥接模式与其他结构型模式的区别很多人会把桥接模式和策略模式搞混。两者确实很像都是通过组合来解耦。但区别在于意图策略模式关注的是“算法的可替换性”它通常只有一个维度的变化桥接模式关注的是“多维度的独立扩展”它至少有两个维度。还有适配器模式它是为了让两个不兼容的接口能一起工作属于“事后补救”桥接模式是在设计阶段就预见了多维度变化属于“事前规划”。装饰器模式是在不改变接口的前提下增强功能而桥接模式是改变结构来支持多维度扩展。理解这些区别能帮你在实际项目中选对模式。我见过不少项目明明用策略模式就够了非要套桥接结果多了一层不必要的抽象反而增加了理解成本。3. 手把手实现一个桥接模式3.1 场景定义与接口设计我们继续用消息推送系统的例子。需求很明确消息类型和发送渠道是两个独立变化的维度。消息类型可能会增加比如以后加一个“营销消息”发送渠道也可能会增加比如以后加一个“应用内推送”。先定义实现化角色也就是发送渠道接口public interface MessageChannel { void send(String content); }这个接口只有一个方法参数是消息内容。注意这里不传消息类型因为渠道不关心你是什么类型的消息它只负责发。然后定义具体实现化角色public class SmsChannel implements MessageChannel { Override public void send(String content) { System.out.println(通过短信发送 content); } } public class EmailChannel implements MessageChannel { Override public void send(String content) { System.out.println(通过邮件发送 content); } }这两个类很干净只做一件事发送。它们不知道消息是普通的还是紧急的也不需要知道。3.2 抽象化角色的桥接实现接下来是抽象化角色也就是消息抽象类public abstract class Message { protected MessageChannel channel; public Message(MessageChannel channel) { this.channel channel; } public abstract void send(String content); }这里的关键是protected MessageChannel channel这个字段它就是那座“桥”。通过构造函数注入消息类持有了一个渠道的引用。注意我用的是protected而不是private因为子类可能需要访问这个渠道来做一些定制操作。然后是修正抽象化角色public class NormalMessage extends Message { public NormalMessage(MessageChannel channel) { super(channel); } Override public void send(String content) { channel.send(【普通】 content); } } public class UrgentMessage extends Message { public UrgentMessage(MessageChannel channel) { super(channel); } Override public void send(String content) { channel.send(【紧急】 content); System.out.println(紧急消息已记录日志); } }普通消息就是在内容前加个标记紧急消息除了加标记还要记录日志。这些定制逻辑都在消息这一侧完成渠道完全不用改。3.3 客户端调用与运行时切换客户端代码是这样的public class Client { public static void main(String[] args) { MessageChannel sms new SmsChannel(); MessageChannel email new EmailChannel(); Message normalSms new NormalMessage(sms); normalSms.send(系统维护通知); Message urgentEmail new UrgentMessage(email); urgentEmail.send(服务器宕机告警); // 运行时切换渠道 Message urgentSms new UrgentMessage(sms); urgentSms.send(数据库连接失败); } }输出结果通过短信发送【普通】系统维护通知 通过邮件发送【紧急】服务器宕机告警 紧急消息已记录日志 通过短信发送【紧急】数据库连接失败 紧急消息已记录日志你看同样的紧急消息可以配短信渠道也可以配邮件渠道。渠道和消息类型完全解耦各自独立扩展。以后要加一个“应用内推送”渠道只需要写一个PushChannel实现类所有消息类型自动支持。要加一个“营销消息”类型只需要写一个MarketingMessage继承类所有渠道自动支持。提示在实际项目中渠道的实例通常不需要每次 new可以用工厂模式或依赖注入来管理。桥接模式负责结构解耦实例管理交给其他机制。4. 实际项目中的经验与避坑指南4.1 什么时候不该用桥接模式我见过最典型的误用是一个只有单一变化维度的场景硬套桥接。比如一个日志系统只有“日志级别”一个维度在变有人非要拆出一个“日志输出器”接口再搞一个“日志抽象类”持有输出器。结果代码多了一层但灵活性没有任何提升因为输出方式根本不会变。判断标准很简单如果你画不出两个独立变化的维度就不要用桥接模式。一个维度用继承或策略模式就够了。两个维度才是桥接的甜点区。三个维度桥接模式处理起来就开始吃力了可能需要考虑其他方案。还有一个坑是“过度设计”。有些开发者学了桥接模式之后看什么代码都觉得应该拆成两个维度。结果一个简单的CRUD功能被拆成了七八个类维护成本反而上升。设计模式是工具不是信仰。能用简单方案解决的问题就不要上模式。4.2 桥接模式在框架中的真实应用桥接模式在开源框架里其实很常见只是很多人没意识到。比如JDBC的架构就是一个典型的桥接模式应用。DriverManager和Connection是抽象化角色各个数据库厂商的驱动实现是实现化角色。你写的业务代码不关心底层是MySQL还是PostgreSQL只关心Connection接口。数据库厂商也不关心你用什么业务逻辑只负责实现驱动接口。再比如图形界面框架里的“窗口”和“窗口实现”。窗口抽象类定义了绘制、最小化、关闭等操作而具体的窗口实现比如不同操作系统的窗口渲染作为实现化角色注入。这样同一套窗口逻辑可以跑在不同平台上。理解这些真实应用比背UML图有用得多。我建议你在学习任何设计模式时都去找一个你熟悉的框架看看它是怎么用的。这种“锚定”记忆比死记硬背强十倍。4.3 常见问题速查表问题现象可能原因排查思路解决方式类数量爆炸继承体系超过三层多个维度耦合在继承链中梳理变化维度看是否有两个以上独立变化方向将其中一个维度抽离为接口用组合替代继承桥接后代码更复杂了维度划分不合理或只有一个维度检查是否真的有两个独立变化维度如果只有一个维度改用策略模式或直接继承运行时切换实现后状态异常实现化角色有状态且未正确重置检查实现化角色是否无状态或切换时是否需要清理尽量让实现化角色无状态有状态时提供重置方法抽象化角色和实现化角色职责混淆接口设计时职责边界不清检查实现化角色是否包含了业务逻辑实现化角色只做“怎么做”抽象化角色负责“做什么”新增维度时改动量大桥接的粒度太粗或太细评估维度划分是否与业务变化频率匹配按变化频率和业务边界重新划分维度这张表里的每一条都是我或身边同事真实踩过的坑。特别是最后一条维度划分的粒度非常考验经验。分得太粗灵活性不够分得太细类数量又上去了。我的经验是按照业务变化频率来划分。变化频率相近的放在同一个维度变化频率差异大的拆成不同维度。4.4 一个容易被忽略的细节桥接的方向性桥接模式里抽象化角色持有实现化角色的引用这个方向是固定的。你不能反过来让实现化角色持有抽象化角色的引用那样就形成了循环依赖代码会变得非常难维护。但实际项目中有时候确实需要实现化角色回调抽象化角色。比如发送渠道在发送完成后需要通知消息对象更新状态。这时候怎么办我的做法是引入一个回调接口让实现化角色依赖这个回调接口而不是直接依赖抽象化角色。这样既实现了双向通信又避免了循环依赖。这个技巧在框架开发中特别有用。很多框架的“监听器”机制本质上就是这种回调接口的应用。5. 从桥接模式延伸出的设计思维5.1 维度思维看见代码里的“隐形维度”桥接模式教给我的最大收获不是这个模式本身而是一种“维度思维”。什么叫维度思维就是在看一个需求时能识别出其中独立变化的维度。举个例子。一个电商系统里的“订单”表面上看是一个整体但拆开看至少有这几个维度订单类型普通订单、团购订单、秒杀订单、支付方式支付宝、微信、银行卡、配送方式快递、自提、同城配送。这三个维度各自独立变化如果用继承来写类数量是乘法关系。用桥接的思路每个维度独立扩展类数量是加法关系。这种思维一旦建立起来你在设计阶段就能预见到未来的扩展点而不是等到类爆炸了才去重构。我现在的习惯是拿到需求先画一张表横轴是各种变化维度纵轴是每个维度下的取值。如果发现有两个以上维度且取值会持续增加桥接模式就是候选方案。5.2 组合优于继承的边界“组合优于继承”是设计模式里的黄金法则但很多人把它理解成了“继承一无是处”。这是矫枉过正。继承在表达“is-a”关系时依然是最清晰的方案。比如“狗是一种动物”用继承天经地义。桥接模式体现的是“组合优于继承”在多维度场景下的应用。它不是说继承不好而是说当继承导致类爆炸时应该考虑用组合来替代部分继承关系。具体来说把其中一个维度从继承链中抽出来变成组合关系。我的一般原则是如果继承层次超过两层或者类名里出现了“And”就应该停下来想想是不是该用桥接了。这个原则帮我避免了很多次过度设计也帮我识别出了很多次该重构的信号。5.3 桥接模式与依赖倒置原则的关系桥接模式之所以能实现两个维度的独立变化根本原因是它遵循了依赖倒置原则。抽象化角色依赖的是实现化角色的接口而不是具体实现。这意味着高层模块消息逻辑不依赖低层模块具体渠道两者都依赖抽象。这个原则的价值在于当低层模块变化时高层模块不受影响。新增一个渠道消息类完全不用改。新增一个消息类型渠道类完全不用改。这种“互不干扰”的扩展能力是桥接模式最核心的竞争力。我在带新人的时候经常让他们做一个练习把一个用继承写的多维度场景改写成桥接模式。改完之后让他们对比两种方案的类图感受“乘法变加法”的直观冲击。这个练习做过一次基本就忘不掉了。5.4 实际项目中的取舍桥接不是银弹最后说点实在的。桥接模式虽然好但它也有成本。最直接的成本是类的数量增加了——虽然从乘法变成了加法但绝对值还是多了。另一个成本是理解成本新加入项目的人需要理解两个维度的关系比看一个继承链要费脑子。所以我的建议是在项目早期如果变化维度还不明确不要急着上桥接。先用最简单的方案实现等维度真的开始膨胀了再重构也不迟。重构的时候桥接模式是一个非常好的目标形态。但一开始就上桥接很可能是在为想象中的变化买单。我自己的项目里桥接模式的使用频率大概在5%左右。大部分场景用简单的继承或策略就够了。但那5%的场景如果不用桥接代码会变得非常难以维护。识别出这5%就是经验的价值所在。注意设计模式的学习重点不是记住结构而是理解它背后的取舍逻辑。知道什么时候用比知道怎么用更重要。
阅读完成 · 觉得有帮助？
