十多年前我刚自学软件设计模式的时候最让我头疼的其实是桥接模式。单例一眼就能懂工厂模式几个示例就通透了但桥接模式这个“四不像”……为什么消息发送要搞两层为什么不干脆让“紧急短信”、“紧急邮件”、“普通短信”、“普通邮件”都直接继承一个父类直到自己在项目里遇到“渠道”和“级别”这两个维度垂直膨胀的问题才真正明白类爆炸的宿命里继承不是答案组合才是。桥接模式就是“抽象维度”与“实现维度”之间最好的黏合剂。而且有意思的是这个模式名和网络里的“虚拟机桥接”共用同一个词根很多朋友在“笔记本电脑安装虚拟机桥接模式”时还遇到过“无法获取IP”的怪事这次我把软件层面的桥接原理和网络层面的排查笔记一起整理成这篇小黑的学习笔记。1. 桥接模式到底要解决什么问题1.1 先从“类爆炸”敲一棒子很多人看桥接模式的第一眼会觉得“这不就是接口加组合吗有什么好单独学一个模式的”思路方向没错但桥接模式存在的意义恰恰是把“接口加上组合”这件事聚焦在一个特定的变化结构上。假设我们要做一个消息推送系统。消息有两个变化维度一个是消息本身的紧急程度分为普通消息和紧急消息另一个是消息的发送渠道分为短信、邮件、群聊机器人。如果用继承思维来设计先建一个基础消息类派生出普通消息和紧急消息再把发送渠道继承进去……那就需要普通短信、普通邮件、普通群聊、紧急短信、紧急邮件、紧急群聊六个类。如果后面又增加“定时消息”这个维度类数量会变成三乘三等于九个。再增加一个“敏感级别”类数量又要乘一次。等到渠道、级别、模板、频率、归档这些维度叠加起来类数量的膨胀会直接失控。继承适合描述“你就是一个”的强耦合关系并不适合描述“你能任意组合成想要的样子”。桥接模式正是在这个地方摆正思路把“消息的抽象特征”和“消息的发送渠道”两个维度从继承关系中拆开分别按自己的规律延伸。抽象维度那边管消息是什么实现维度那边管消息怎么发出去。具体哪条消息用哪个渠道运行期由组合关系决定。1.2 生活类比遥控器和电视机每次解释桥接模式我都爱用遥控器举例。你家电视机的品牌、屏幕驱动、解码芯片这些都是电视机厂商的事遥控器的按键布局、内部编码则是遥控器厂商的事。两个厂商各自独立演进互不依赖却能通过统一的红外协议或蓝牙协议连接起来。遥控器只需要知道自己发出了一个“换台”的抽象指令具体到电视机哪个芯片如何响应这个命令那是电视机内部的事情。这个类比最妙的地方在于你可以正常换一台新电视机旧遥控器几乎不用改也可以换一个最新款遥控器电视机也能继续用。两边变化互不拖累。这就是桥接模式“让抽象和实现可以独立变化”的含义。抽象维度延伸出普通遥控器、语音遥控器、学习型遥控器实现维度延伸出显示器、投影仪、电视机盒子——它们之间通过一根协议缆线连接在代码里这根缆线就是实现者接口的引用。2. 桥接模式的结构与角色拆解2.1 四个角色的边界桥接模式的标准结构里有四个角色缺一个都不完整抽象化Abstraction定义上层抽象接口并持有实现者接口的引用。它是协调抽象维度与实现维度的枢纽。扩展抽象化RefinedAbstraction继承自抽象化进一步扩展抽象侧的职责。比如普通消息和紧急消息分别做预处理逻辑。实现者接口Implementor定义底层实现类必须提供的能力比如“发送”这个动作的接口。具体实现者ConcreteImplementor实现者接口的真正执行者不同发送渠道自己处理自己的协议。简单来说抽象化和扩展抽象化是一棵继承树实现者接口和具体实现者是另一棵继承树两棵树通过“抽象化持有实现者接口引用”联系起来。左边的抽象维度可以自由生长右边的实现维度也可以自由生长互相不绑死。2.2 类之间的关系如果要在纸上画类图最核心的关系线是这样的Abstraction类底边画一条指向Implementor接口的关联线线上标注“implementor”RefinedAbstraction向上继承AbstractionConcreteImplementor向上实现Implementor。也就是说抽象侧的子类与实现侧的子类之间没有任何直接继承关系代码里也不该直接调用具体实现类的细节方法。如果代码里出现“紧急消息调用的是某个具体短信类的方法”那说明你没在写桥接只是在套壳。还有一个容易被忽略的细节Abstraction类并不限制子类如何获得Implementor引用构造函数注入、方法参数传递、工厂返回都可以。但首选构造器注入。原因很简单让扩展抽象类的实例在创建时就把渠道绑定好逻辑清晰测试时也方便如果运行时需要换渠道再通过setter替换引用即可。3. 用代码把桥接模式讲明白一个消息发送系统的重构3.1 反面案例用继承做出来的“六边形战士”先看一个反面例子。假设用继承实现“紧急短信”、“普通邮件”这种六类消息。用Java写出来大概是这样的public abstract class Message { protected String content; public abstract void send(); } public class NormalMessage extends Message { Override public void send() { System.out.println(短信渠道发送普通消息 content); } } public class UrgentMessage extends Message { Override public void send() { System.out.println(短信渠道发送紧急消息 content); } }接着还要继续派生邮件版本public class NormalMailMessage extends NormalMessage { Override public void send() { System.out.println(邮件渠道发送普通消息 content); } } public class UrgentMailMessage extends UrgentMessage { Override public void send() { System.out.println(邮件渠道发送紧急消息 content); } }一旦“渠道数量”和“消息类型”继续增长子类数就是消息类型数乘以渠道数。问题更突出的是很多子类的send()方法逻辑高度雷同只是输出源不同。把这些相似逻辑埋进继承链深处既不直观也很难做单元测试。最难受的是每次新增第三种渠道都得一口气写N个子类改起来想死。3.2 重构后的桥接版代码现在用桥接模式重写。第一步定义实现侧接口也就是“发送”这个动作public interface MessageSender { void send(String content); }第二步实现不同的发送渠道。渠道类负责跟真实通道打交道例如调用短信网关、连接邮件服务器等public class SmsSender implements MessageSender { Override public void send(String content) { // 调用短信网关的真实逻辑例如HTTP接口、签名校验等 System.out.println([短信渠道] 发送 content); } } public class EmailSender implements MessageSender { Override public void send(String content) { // 走邮件服务器组装邮件协议 System.out.println([邮件渠道] 发送 content); } } public class ChatBotSender implements MessageSender { Override public void send(String content) { // 调用群聊机器人的Webhook System.out.println([群聊渠道] 发送 content); } }第三步定义抽象侧的“消息”类。它不关心最终怎么发只定义消息的类型层级并持有一个MessageSender字段public abstract class Message { protected MessageSender sender; protected String content; public Message(MessageSender sender, String content) { this.sender sender; this.content content; } public abstract void send(); }第四步抽象侧扩展子类。普通消息发送前做敏感信息脱敏紧急消息发送前加急标识public class NormalMessage extends Message { public NormalMessage(MessageSender sender, String content) { super(sender, content); } Override public void send() { String processed content.replaceAll((?手机号前3位)\\d{4}, ****); sender.send(processed); } } public class UrgentMessage extends Message { public UrgentMessage(MessageSender sender, String content) { super(sender, content); } Override public void send() { sender.send([紧急] content); } }客户端组装时非常灵活public class Application { public static void main(String[] args) { MessageSender sms new SmsSender(); MessageSender email new EmailSender(); MessageSender bot new ChatBotSender(); Message normal new NormalMessage(sms, 今晚八点更新部分系统); normal.send(); Message urgent new UrgentMessage(bot, 监控服务告警请立刻查看); urgent.send(); // 运行期动态更换渠道同样简单 Message another new NormalMessage(email, 周报已生成); another.send(); } }对比一下原来要写六个类现在实现侧是三个渠道类抽象侧是两个消息类加一个接口和一个抽象父类。以后新增一个渠道只需要增加一个实现侧类新增一种消息类型只需要增加一个抽象侧子类。两个维度不用互相迁就类爆炸的问题自然消失。3.3 构造器注入不是唯一选择写业务代码时很多同学会问“sender为什么一定要在构造器里传我不能在send()方法里临时传吗”桥接模式并没有把获取实现引用这件事锁死在构造器里构造器注入只是最常用的实践。你完全可以在sendMessage()的时候临时传入一个sender配合策略模式一起用也可以让sender来自抽象层内部的工厂方法比如“根据环境自动选择渠道”。核心约束只有一个上层不直接依赖具体实现类。如果构造器注入导致测试代码麻烦可以搞一个MessageSenderProvider统一提供默认渠道这个思路基本就跟依赖注入容器接上头了。4. 桥接模式的使用边界和选型对比4.1 什么时候才适合用桥接模式网上一堆文章喜欢把桥接模式吹成“万能灵活”。这种话当玩笑听听就好桥接模式有自己的适用场景至少需要满足这几个条件存在两个或两个以上独立变化维度。如果只有一个维度拆开纯属多此一举。两个维度的变化频率都足够高。只有一边会变拆出来的收益很有限。抽象侧和实现侧确实需要独立扩展。如果新增消息类型时必然要动渠道代码那拆开反而增加不必要的接口层。运行期可能需要切换实现。桥接模式最大的优势之一就是把切换成本压低到“换一个引用”。反例也很好举一个只有固定渠道、也看不到扩展计划的消息系统直接用接口加一种实现就好完全不用搬出桥接。强行引入桥接会多出两层继承体系代码量翻倍阅读成本急剧上升。4.2 桥接模式和策略模式是不是很像很多读者会把桥接和策略搞混。它们都大量使用组合都强调面向接口编程。到底差在哪里看意图。策略模式属于行为型模式解决的是“同一个上下文里不同算法可以自由切换”桥接模式属于结构型模式解决的是“两个维度的类体系解耦各自独立变化”。简单说策略模式专注于上下文内算法的替换上下文本身保持不变桥接模式则要求抽象侧和实现侧两套体系都保留扩展空间。看耦合导向。策略模式中上下文对象和策略对象是平级关系双方都在业务领域内自由活动桥接模式有明确的“抽象侧”和“实现侧”的先后、层级关系实现侧通常更靠近基础设施层比如“消息渠道”显然比“消息类型”更接近底层。看组合程度。桥接模式里的实现者接口往往代表底层能力比如send()、open()、close()这类原子能力策略模式里的算法接口往往更“厚”直接封装一整个业务规则。当然真实项目里这两种模式经常配合使用。桥接模式中sender的具体选择可能又需要策略模式来决定“当前用哪种渠道最优”sender本身也可以是策略集合。模式之间永远可以互相协作别把它们当教条隔离。4.3 桥接模式与适配器模式的对比实际选型时桥接模式和适配器模式也是被并列对比的高频问题对比项桥接模式适配器模式模式类型结构型结构型核心意图把抽象与实现解耦使两个维度独立变化把一个接口转换成客户端期望的另一个接口使用时机设计阶段就拆双维度通常用于集成阶段处理接口不匹配角色关系抽象侧与实现侧是合作极适配器充当“翻译官”一句话直觉适配器是事后翻译官桥接是开局前就让双方各自独立的合伙人。网上有说法是“适配器可以让桥接更好地工作”这话不假。例如老系统里有一个只有sendSMS(String msg)方法的渠道类与MessageSender接口的send(String content)不匹配写一个Adapter包装一下就能接上桥接结构。5. 热词实战笔记本电脑安装虚拟机桥接模式无法获取IP5.1 这个桥接和设计模式是同一个理念聊完了软件设计模式再来处理热词“笔记本电脑安装虚拟机桥接模式无法获取IP”背后的实际问题。这里有个很值得玩味的点虚拟网络里的“桥接”和设计模式的“桥接”天然同构。虚拟机桥接模式Bridged Network会把虚拟机虚拟出来的网卡连接到宿主机的一块物理网卡上让虚拟机在局域网里以独立设备身份参与通信。它就像在一台真实交换机上插了一根新网线局域网里的其他设备会认为虚拟机就是个普通节点会正常向DHCP服务器请求IP。这跟NAT模式那种“宿主机帮你转发”的模式完全不同更接近一台物理主机待在局域网里的真实感受。5.2 排查顺序从“看起来没问题”开始找不到IP的问题十有八九出在下面几个环节。建议按顺序排查别东点一下西点一下先确认虚拟机当前的网络模式。在VMware里打开“虚拟机设置”确认网络连接选择的是“桥接模式”VirtualBox里确认“连接方式”是“桥接网卡”。有些朋友明明开着NAT模式却抱怨桥接获取不到IP属于第一步就没走对。确认桥接绑定的物理网卡。这是笔记本上最大的坑位。笔记本通常同时有有线网口、无线网卡甚至还有一种虚拟网卡。VMware的“自动桥接”默认绑定时可能会选错。如果你正用Wi-Fi联网而虚拟网络编辑器把VMnet0绑定到有线网卡上虚拟机当然拿不到IP。正确做法是手动指定为“当前活跃的无线网卡”VirtualBox则在“全局设置 → 网络”里勾选对应网卡。检查宿主机物理网卡是否被“Internet连接共享”占用。在Windows“网络和共享中心 → 更改适配器设置”里如果发现某个网络连接上出现了“共享”标志说明它正在被热点共享功能占用。ICS一旦开启会导致桥接链路冲突。建议先取消共享再测试虚拟机。在虚拟机系统内手动刷新IP。Windows虚拟机打开命令提示符管理员ipconfig /release ipconfig /renewLinux虚拟机可以用dhclient或在NetworkManager里重新连接sudo dhclient sudo systemctl restart NetworkManager如果虚拟机跑在VMware上还可以通过“可移动设备 → 网络适配器”执行断开再连接强制重新协商这招有时候比敲命令还管用。检查DHCP服务器是否真正在分发地址。如果宿主机采用拨号方式接入互联网没有路由器做DHCP分发那虚拟机就像开着自动获取却找不到服务器的租客永远等不到地址。这种情况在酒店网络、公司临时网络里比较典型。重置虚拟网络配置。VMware进入“编辑 → 虚拟网络编辑器”把VMnet0删掉再重建一次“桥接模式”如果还不行恢复默认设置。VirtualBox则可在主机端重新安装“VirtualBox桥接网络驱动”。检查宿主机安全防护软件的网络拦截。部分安全软件会在网卡驱动层插入过滤组件虚拟机的DHCP请求可能被当成异常数据包直接丢弃。可以先临时关闭网络防护做测试确认后再把虚拟机的网络进程加入白名单。5.3 一个真实的笔记本无线上网案例这里分享一个我近期遇到的典型场景。朋友用笔记本物理机连接家里无线Wi-Fi虚拟机用VirtualBox桥接绑定无线网卡结果虚拟机开自动获取IP等了30秒什么都没下来。按上面的流程走了一遍虚拟机设置没问题桥接绑定的是无线网卡宿主机无线网卡明明有网络。随后在VirtualBox里把桥接驱动重新勾选了一遍依然卡住。最后把宿主机Wi-Fi断开重新连接一次虚拟机立刻拿到了192.168.1.x的地址。原因其实很简单无线桥接状态下宿主机无线网卡与虚拟化驱动之间的连接状态过期了虚拟机的DHCP请求发出去后没人应答。宿主机网卡重置之后桥接链路恢复正常。这个案例给到的教训是无线场景下的桥接本质上依赖物理网卡驱动和虚拟化桥接驱动之间的协作。遇到“虚拟机桥接获取不到IP”这种问题第一反应不应该是重装系统先尝试断开宿主机Wi-Fi重新连接或者去路由器管理后台把虚拟机当前的MAC地址占一个静态IP绑定。如果还不行再考虑外接网卡和适配器驱动的因素。5.4 换一种模式不是所有场景都非得“桥接”如果桥接一时半会儿处理不好也先别钻牛角尖退回NAT模式往往是个理智选择。NAT模式下虚拟机通过宿主机共享IP访问外部网络不需要在局域网里分配独立IP很快就能上网。虽然局域网内其他设备不能直接访问它但对于大多数只是上网、下载、做开发联调的虚拟机来说完全够用。仅主机模式则适合搭一个不接入外部网络的私有网络用于本地虚拟机互联和调试。模式IP获取方式局域网可见性适合场景桥接模式从路由器DHCP获取局域网IP可见虚拟机需要作为独立节点接入局域网服务NAT模式宿主机共享网络虚拟机走内部子网宿主机之外不可见虚拟机只需要上网、开发、测试仅主机模式宿主机构建私有网段对外不可见本地隔离网络实验、专属调试环境6. 桥接模式的学习心得与查漏补缺兜兜转转到这里我想把学习桥接模式的整个过程沉淀成几个更贴近实战的记忆点。第一个判断窍门拿到一个需求先问自己“这里有几个维度在变化”如果答案是两个或更多而且这些维度各自变化都不可控优先考虑桥接。如果只有一个维度老老实实面向接口编程就行别硬套。第二个代码习惯实现侧接口尽量小。桥接模式的实现者接口越薄越好比如只有send()、open()、close()这种最基本动作。接口越薄越容易适配各种外部实现如果往下看会变成一个十几个方法的大杂烩说明这个实现侧本身还得再拆。第三个关于抽象侧与实现侧友好相处的问题抽象侧只暴露“业务级”方法比如“发送消息”、“播放音频”、“渲染窗口”绝不暴露“网关地址”、“端口号”、“编码格式”这类底层细节。跨维度引用尽量通过构造器传入让依赖在创建时刻固定下来这样单元测试时可以用mock实现替换真实渠道。设计模式和网络里的桥接其实都在说同一件事解耦是让每个部分都能独立变化的前提独立变化又是降低维护成本的关键。学习桥接模式并不意味着每处代码都要做两层皮而是让你在维度增长真正来临之前手里已经握住了方案。真到那个时刻你会感谢自己当初花时间看懂了它。