戰(zhàn)：用組合替代繼承，破解業(yè)務(wù)代碼類爆炸困境)
寫了好幾年的業(yè)務(wù)代碼我越來越覺得設(shè)計(jì)模式這東西不是用來“背”的而是用來“救火”的。今天就聊一個(gè)我實(shí)際項(xiàng)目里反復(fù)用到的結(jié)構(gòu)型模式——橋接模式Bridge Pattern。先看一個(gè)我在真實(shí)開發(fā)中遇到的場景。某次接到一個(gè)需求要做一套跨平臺(tái)的文件上傳組件形態(tài)上要支持普通上傳、分片上傳、斷點(diǎn)續(xù)傳三種類型底層傳輸協(xié)議又要同時(shí)兼容HTTP、FTP、本地存儲(chǔ)三種方式。如果按傳統(tǒng)繼承思路去寫接口設(shè)計(jì)會(huì)直接變成三乘三等于九個(gè)實(shí)現(xiàn)類如果后續(xù)再加一種新的傳輸協(xié)議就得新增三個(gè)實(shí)現(xiàn)類改動(dòng)面很大。這正是橋接模式最典型的應(yīng)用時(shí)機(jī)——當(dāng)某個(gè)維度在獨(dú)立變化時(shí)用組合替代繼承把兩個(gè)維度的變化徹底解耦。這篇內(nèi)容我會(huì)拆開講透橋接模式的核心思想、四類角色、代碼實(shí)現(xiàn)和實(shí)戰(zhàn)中的判斷標(biāo)準(zhǔn)尤其會(huì)把“什么時(shí)候用橋接、什么時(shí)候別用橋接”講清楚因?yàn)檫@是我見過最多人踩坑的地方。無論你是剛學(xué)設(shè)計(jì)模式的新手還是寫了好幾年業(yè)務(wù)代碼但總覺得模式“用不上”的同學(xué)這篇應(yīng)該都能給你一些啟發(fā)。1. 橋接模式到底在解決什么問題1.1 繼承帶來的“類爆炸”困境我們先看繼承為什么會(huì)出問題。假設(shè)你要設(shè)計(jì)一套消息推送系統(tǒng)消息的展示形態(tài)有普通消息、加急消息、定時(shí)消息三種消息的發(fā)送渠道又有站內(nèi)信、短信、IM平臺(tái)三種。用繼承的思路你會(huì)先定義一個(gè)抽象的消息基類然后為每一種“形態(tài) 渠道”的組合創(chuàng)建一個(gè)子類于是得到九個(gè)類UrgentInAppMessage UrgentSmsMessage UrgentImMessage ScheduledInAppMessage ScheduledSmsMessage ScheduledImMessage NormalInAppMessage NormalSmsMessage NormalImMessage這些類的名字本身就暴露了問題命名里同時(shí)出現(xiàn)兩個(gè)維度的特征說明兩個(gè)維度的變化被強(qiáng)行綁死在繼承體系里了。如果以后要新增一個(gè)“語音消息”形態(tài)就得再寫三個(gè)子類類數(shù)量呈乘法增長每新增一個(gè)維度整個(gè)繼承樹的高度和廣度都跟著膨脹。這種寫法的核心矛盾在于兩個(gè)并不相關(guān)的變化因素被迫耦合在了一起。消息的“形態(tài)變化”和“渠道變化”本質(zhì)上是可以獨(dú)立演進(jìn)的但繼承把它們捆綁成一個(gè)整體任何一端的改動(dòng)都會(huì)波及整個(gè)類的集合。代碼量的膨脹還是小事真正的麻煩在于維護(hù)成本——你很難在九個(gè)幾乎長得差不多的類里精準(zhǔn)修改某一段邏輯也很難在測試時(shí)覆蓋所有組合。1.2 組合優(yōu)先把乘法換成加法橋接模式的處理思路就完全不同了。它把“形態(tài)”和“渠道”抽象成兩個(gè)獨(dú)立的結(jié)構(gòu)然后用組合的方式把它們連接起來。還是消息推送這個(gè)場景調(diào)整后的類結(jié)構(gòu)是這樣的一個(gè)消息抽象類包含形態(tài)邏輯內(nèi)部持有發(fā)送渠道的引用三個(gè)形態(tài)子類普通、加急、定時(shí)各自實(shí)現(xiàn)自己的業(yè)務(wù)邏輯三個(gè)發(fā)送渠道實(shí)現(xiàn)類站內(nèi)信、短信、IM平臺(tái)各自實(shí)現(xiàn)發(fā)送協(xié)議。這時(shí)候類數(shù)量是“三個(gè)形態(tài) 三個(gè)渠道 六個(gè)類”。形態(tài)新增一種類數(shù)量變成“四加三等于七個(gè)”渠道新增一種類數(shù)量變成“三加四等于七個(gè)”。組合總數(shù)在增加但類的數(shù)量始終是相加關(guān)系而不是相乘關(guān)系。這個(gè)加法和乘法的區(qū)別就是橋接模式最底層的價(jià)值。你仔細(xì)想想一個(gè)系統(tǒng)里如果存在M個(gè)“抽象化”變體和N個(gè)“實(shí)現(xiàn)化”變體用繼承體系需要M乘N個(gè)類橋接模式只需要M加N個(gè)類加一個(gè)組合引用。系統(tǒng)越復(fù)雜、維度越多這種結(jié)構(gòu)優(yōu)勢就越明顯。1.3 為什么不是簡單的“接口隔離”有同學(xué)可能會(huì)問我把接口定義好每個(gè)實(shí)現(xiàn)類里都注入一個(gè)渠道對象這不就是組合嗎和橋接模式有什么關(guān)系這是個(gè)好問題。普通組合強(qiáng)調(diào)的是“對象內(nèi)部持有一個(gè)服務(wù)對象”例如一個(gè)業(yè)務(wù)服務(wù)里注入一個(gè)數(shù)據(jù)庫操作類。但橋接模式更進(jìn)一步它強(qiáng)調(diào)的是抽象部分和實(shí)現(xiàn)部分各自擁有一套獨(dú)立的繼承體系并且這兩個(gè)體系都允許獨(dú)立擴(kuò)展。換句話說橋接模式是一種“有意識(shí)的、結(jié)構(gòu)化的組合”它要求你在設(shè)計(jì)之初就識(shí)別出兩個(gè)變化維度然后分別為它們建立抽象邊界最后通過組合把它們橋接起來。光在代碼里使用接口和組合不代表就是橋接模式——那只是面向?qū)ο笤O(shè)計(jì)的基本功。橋接模式的判別標(biāo)準(zhǔn)是是否存在兩條可以獨(dú)立變化的繼承鏈以及它們之間是否通過組合關(guān)聯(lián)。這個(gè)標(biāo)準(zhǔn)后面我會(huì)反復(fù)提到因?yàn)樗菂^(qū)分橋接模式和其他模式的關(guān)鍵。2. 橋接模式的核心角色與場景建模2.1 經(jīng)典場景遙控器與設(shè)備講解橋接模式繞不開一個(gè)經(jīng)典例子——遙控器和電器設(shè)備。這個(gè)例子的巧妙之處就在于它天然具備兩個(gè)獨(dú)立的變化維度遙控器設(shè)備端遙控器本身的形態(tài)和功能、控制端設(shè)備本身的種類和協(xié)議。想象你是某家電廠商的軟件負(fù)責(zé)人。你負(fù)責(zé)的遙控器產(chǎn)品線有基礎(chǔ)版和高級(jí)版兩種基礎(chǔ)版支持開關(guān)機(jī)和音量調(diào)節(jié)高級(jí)版額外支持靜音和語音控制?？刂频脑O(shè)備有電視和收音機(jī)兩種它們的開機(jī)邏輯、音量調(diào)節(jié)方式完全不同甚至通信協(xié)議都不一樣。如果用繼承實(shí)現(xiàn)類圖會(huì)是這樣的形狀先定義一個(gè)遙控器基類再分別派生出基礎(chǔ)遙控器-電視、基礎(chǔ)遙控器-收音機(jī)、高級(jí)遙控器-電視、高級(jí)遙控器-收音機(jī)四個(gè)具體類。哪怕遙控器外形只增加一個(gè)“極簡版”設(shè)備列表再增加一個(gè)“投影儀”類數(shù)量就會(huì)從四個(gè)變成九個(gè)。而橋接模式的處理方式是把遙控器和設(shè)備拆成兩套獨(dú)立的繼承鏈遙控器這一側(cè)抽象化的遙控器基類RemoteControl、基礎(chǔ)遙控器BasicRemoteControl、高級(jí)遙控器AdvancedRemoteControl設(shè)備這一側(cè)實(shí)現(xiàn)化的設(shè)備接口Device、電視Television、收音機(jī)Radio遙控器內(nèi)部持有一個(gè)設(shè)備引用組合關(guān)系在這里建立。以后遙控器產(chǎn)品線隨便加新品設(shè)備產(chǎn)品線隨便加設(shè)備彼此互不干擾數(shù)量始終是加法關(guān)系。這就是橋接模式設(shè)計(jì)的核心形態(tài)——兩棵獨(dú)立的“樹”之間通過一個(gè)組合引用搭起橋。2.2 四類角色逐一拆解橋接模式的官方命名體系里有四類經(jīng)典角色理解它們是掌握這個(gè)模式的關(guān)鍵抽象化Abstraction抽象化定義的是“控制方”的抽象接口。以遙控器場景為例RemoteControl就是抽象化角色。它內(nèi)部持有一個(gè)實(shí)現(xiàn)化的引用Device并把用戶可感知的高層操作開關(guān)機(jī)、音量加減定義為接口。需要注意的是抽象化里通常會(huì)維護(hù)一個(gè)成員變量這個(gè)成員變量的類型是“實(shí)現(xiàn)化接口”而不是某個(gè)具體實(shí)現(xiàn)類。擴(kuò)展抽象化RefinedAbstraction擴(kuò)展抽象化是抽象化接口的子類。例如BasicRemoteControl和AdvancedRemoteControl就是兩個(gè)擴(kuò)展抽象化。它們可以改變高層操作的具體邏輯也可以增加新的高層操作比如高級(jí)版的靜音功能但都不需要關(guān)心底層設(shè)備如何執(zhí)行這些操作。實(shí)現(xiàn)化Implementor實(shí)現(xiàn)化定義的是“被控制方”的底層操作接口。本例中的Device就是實(shí)現(xiàn)化接口它聲明了turnOn、turnOff、setVolume這類底層動(dòng)作。這些動(dòng)作是相對原子化的通常一個(gè)動(dòng)作對應(yīng)一個(gè)最基本的硬件操作或協(xié)議指令。具體實(shí)現(xiàn)化ConcreteImplementor具體實(shí)現(xiàn)化是實(shí)現(xiàn)化接口的具體類例如Television和Radio。每個(gè)具體實(shí)現(xiàn)化類都要完整實(shí)現(xiàn)設(shè)備接口定義的所有底層操作并依據(jù)自身硬件特性決定執(zhí)行細(xì)節(jié)。你可能會(huì)覺得這套命名有點(diǎn)抽象。換個(gè)角度記抽象化 用戶能看到的操作層實(shí)現(xiàn)化 底層平臺(tái)的具體執(zhí)行層擴(kuò)展抽象化 操作層的不同款式具體實(shí)現(xiàn)化 平臺(tái)層的不同產(chǎn)品。2.3 關(guān)鍵設(shè)計(jì)決策誰握著誰的引用橋接模式里最容易搞反的一個(gè)問題就是引用的方向。正確的做法是抽象化持有實(shí)現(xiàn)化的引用而不是反過來。也就是說RemoteControl內(nèi)部存在一個(gè)Device類型的字段創(chuàng)建遙控器時(shí)通過構(gòu)造器把具體的設(shè)備傳進(jìn)去。這個(gè)方向?yàn)槭裁床荒芊匆驗(yàn)閺臉I(yè)務(wù)流程看遙控器是“發(fā)起動(dòng)作的一方”設(shè)備是“接收動(dòng)作并執(zhí)行的一方”。遙控器需要知道自己在控制什么設(shè)備從而調(diào)用對應(yīng)設(shè)備的方法反過來設(shè)備完全不需要知道是誰在控制自己——電視不會(huì)因?yàn)檫b控器掛了就沒法開機(jī)內(nèi)置的物理按鍵同樣能開機(jī)。從依賴關(guān)系的角度看抽象化依賴實(shí)現(xiàn)化接口正好符合依賴倒置原則高層模塊遙控器不依賴低層模塊具體設(shè)備而是依賴抽象Device接口。如果反將其道讓設(shè)備持有遙控器的引用就會(huì)出現(xiàn)一種毫無道理的逆向依賴——設(shè)備要“知道”遙控器如何操作自己這對設(shè)備的獨(dú)立復(fù)用是一種破壞也違背了橋接模式解耦的初衷。3. 代碼實(shí)現(xiàn)從Java到TypeScript的完整落地3.1 Java實(shí)現(xiàn)遙控器與設(shè)備的經(jīng)典搭配橋接模式最常見的學(xué)習(xí)語言是Java我們先把完整流程寫一遍。首先是實(shí)現(xiàn)化接口也就是Device/** * 實(shí)現(xiàn)化接口設(shè)備 */ public interface Device { void turnOn(); void turnOff(); void setVolume(int percent); int getVolume(); boolean isEnabled(); }接著是兩個(gè)具體實(shí)現(xiàn)化類電視機(jī)和收音機(jī)/** * 具體實(shí)現(xiàn)化電視機(jī) */ public class Television implements Device { private boolean enabled false; private int volume 20; Override public void turnOn() { this.enabled true; System.out.println(電視機(jī)已開機(jī)); } Override public void turnOff() { this.enabled false; System.out.println(電視機(jī)已關(guān)機(jī)); } Override public void setVolume(int percent) { this.volume Math.max(0, Math.min(100, percent)); System.out.println(電視機(jī)音量設(shè)置為 this.volume); } Override public int getVolume() { return this.volume; } Override public boolean isEnabled() { return this.enabled; } }/** * 具體實(shí)現(xiàn)化收音機(jī) */ public class Radio implements Device { private boolean enabled false; private int volume 30; Override public void turnOn() { this.enabled true; System.out.println(收音機(jī)已開機(jī)); } Override public void turnOff() { this.enabled false; System.out.println(收音機(jī)已關(guān)機(jī)); } Override public void setVolume(int percent) { this.volume Math.max(0, Math.min(100, percent)); System.out.println(收音機(jī)音量設(shè)置為 this.volume); } Override public int getVolume() { return this.volume; } Override public boolean isEnabled() { return this.enabled; } }然后是抽象化角色RemoteControl。注意它的構(gòu)造器參數(shù)是Device接口而不是具體設(shè)備類這是組合關(guān)系成立的關(guān)鍵/** * 抽象化角色遙控器 */ public abstract class RemoteControl { protected Device device; public RemoteControl(Device device) { this.device device; } public abstract void togglePower(); public abstract void volumeUp(); public abstract void volumeDown(); }基礎(chǔ)遙控器和高級(jí)遙控器作為擴(kuò)展抽象化角色/** * 擴(kuò)展抽象化基礎(chǔ)遙控器 */ public class BasicRemoteControl extends RemoteControl { public BasicRemoteControl(Device device) { super(device); } Override public void togglePower() { System.out.println(基礎(chǔ)遙控器執(zhí)行開關(guān)機(jī)); if (device.isEnabled()) { device.turnOff(); } else { device.turnOn(); } } Override public void volumeUp() { device.setVolume(device.getVolume() 5); } Override public void volumeDown() { device.setVolume(device.getVolume() - 5); } }/** * 擴(kuò)展抽象化高級(jí)遙控器 */ public class AdvancedRemoteControl extends RemoteControl { public AdvancedRemoteControl(Device device) { super(device); } Override public void togglePower() { System.out.println(高級(jí)遙控器執(zhí)行開關(guān)機(jī)); if (device.isEnabled()) { device.turnOff(); } else { device.turnOn(); } } Override public void volumeUp() { device.setVolume(device.getVolume() 10); } Override public void volumeDown() { device.setVolume(device.getVolume() - 10); } // 高級(jí)遙控器獨(dú)有功能靜音 public void mute() { device.setVolume(0); System.out.println(已靜音); } }調(diào)用方測試代碼public class BridgePatternDemo { public static void main(String[] args) { Device tv new Television(); RemoteControl basicRemote new BasicRemoteControl(tv); basicRemote.togglePower(); basicRemote.volumeUp(); Device radio new Radio(); AdvancedRemoteControl advancedRemote new AdvancedRemoteControl(radio); advancedRemote.togglePower(); advancedRemote.mute(); } }這段代碼運(yùn)行后輸出如下基礎(chǔ)遙控器執(zhí)行開關(guān)機(jī) 電視機(jī)已開機(jī) 電視機(jī)音量設(shè)置為25假設(shè)初始音量20 高級(jí)遙控器執(zhí)行開關(guān)機(jī) 收音機(jī)已開機(jī) 已靜音 收音機(jī)音量設(shè)置為0觀察這段代碼你會(huì)發(fā)現(xiàn)一個(gè)細(xì)節(jié)BasicRemoteControl和AdvancedRemoteControl里的togglePower方法邏輯幾乎一樣只是標(biāo)識(shí)不同。這是我刻意保留的。兩種遙控器對“開關(guān)機(jī)”這個(gè)操作確實(shí)沒有本質(zhì)區(qū)別但它們在音量調(diào)節(jié)步進(jìn)和擴(kuò)展功能上有差異。真實(shí)項(xiàng)目里這種邏輯相近的情況很常見想要消除重復(fù)可以把公共邏輯上移到抽象化基類但要注意別因此把抽象化基類和實(shí)現(xiàn)化接口又捆死在一起。3.2 TypeScript實(shí)現(xiàn)企業(yè)級(jí)消息推送系統(tǒng)的橋接改造我們看一個(gè)更有現(xiàn)實(shí)感的場景——消息推送服務(wù)。這是我在工程中真正用橋接模式重構(gòu)過的項(xiàng)目類型比遙控器例子更接近業(yè)務(wù)系統(tǒng)。先看初始的問題代碼。假設(shè)系統(tǒng)里有“加急通知”和“定時(shí)通知”兩種消息形態(tài)每種形態(tài)都要能發(fā)到站內(nèi)信、短信、IM平臺(tái)三種渠道。常規(guī)寫法的類結(jié)構(gòu)是這樣的// 未使用橋接模式的錯(cuò)誤示范 class UrgentInAppNotifier { send(title: string, content: string): void { console.log(【站內(nèi)信】加急發(fā)送${title} - ${content}); } } class UrgentSmsNotifier { send(title: string, content: string): void { console.log(【短信】加急發(fā)送${title} - ${content}); } } class ScheduledImNotifier { send(title: string, content: string): void { console.log(【IM平臺(tái)】定時(shí)發(fā)送${title} - ${content}); } }如果照著這個(gè)路子寫九個(gè)類跑不掉。而且你看這個(gè)類命名形態(tài)和渠道倆維度攪在一起哪怕后面只加一種“語音通知形態(tài)”也要同時(shí)改三個(gè)類。用橋接模式重構(gòu)后首先定義渠道接口和三個(gè)渠道實(shí)現(xiàn)/** * 實(shí)現(xiàn)化接口消息發(fā)送渠道 */ export interface MessageSender { sendMessage(title: string, content: string, scheduleTime?: Date): Promiseboolean; } /** * 具體實(shí)現(xiàn)化站內(nèi)信渠道 */ export class InAppSender implements MessageSender { async sendMessage(title: string, content: string, scheduleTime?: Date): Promiseboolean { if (scheduleTime) { console.log(站內(nèi)信已定時(shí)將在 ${scheduleTime.toISOString()} 發(fā)送${title}); } else { console.log(站內(nèi)信發(fā)送${title} - ${content}); } return true; } } /** * 具體實(shí)現(xiàn)化短信渠道注意這里需要對接某短信服務(wù)商的HTTP接口 */ export class SmsSender implements MessageSender { private readonly endpoint: string; constructor(endpoint: string) { this.endpoint endpoint; } async sendMessage(title: string, content: string, scheduleTime?: Date): Promiseboolean { // 真實(shí)項(xiàng)目里這里會(huì)調(diào)用短信服務(wù)商的API并做簽名、限流、重試等處理 console.log(短信發(fā)送至網(wǎng)關(guān) ${this.endpoint}${title} - ${content}); return true; } } /** * 具體實(shí)現(xiàn)化IM平臺(tái)渠道 */ export class ImSender implements MessageSender { private readonly webhook: string; constructor(webhook: string) { this.webhook webhook; } async sendMessage(title: string, content: string, scheduleTime?: Date): Promiseboolean { console.log(IM平臺(tái)推送至 ${this.webhook}${title} - ${content}); return true; } }接著定義抽象化的通知器基類和兩種擴(kuò)展抽象化/** * 抽象化角色消息通知器 */ export abstract class MessageNotifier { protected sender: MessageSender; constructor(sender: MessageSender) { this.sender sender; } abstract notify(title: string, content: string): Promisevoid; } /** * 擴(kuò)展抽象化普通通知 */ export class NormalNotifier extends MessageNotifier { async notify(title: string, content: string): Promisevoid { await this.sender.sendMessage(title, content); } } /** * 擴(kuò)展抽象化加急通知 */ export class UrgentNotifier extends MessageNotifier { async notify(title: string, content: string): Promisevoid { // 加急通知通常會(huì)走優(yōu)先級(jí)更高的通道或追加短信作為兜底 await this.sender.sendMessage(【加急】${title}, content); console.log(已觸發(fā)加急補(bǔ)救邏輯); } }使用側(cè)代碼const inAppSender new InAppSender(); const smsSender new SmsSender(https://sms.example.com/send); const imSender new ImSender(https://im.example.com/webhook); // 加急通知走短信渠道 const urgentSms new UrgentNotifier(smsSender); await urgentSms.notify(服務(wù)器告警, CPU使用率超過90%); // 普通通知走站內(nèi)信渠道 const normalInApp new NormalNotifier(inAppSender); await normalInApp.notify(賬單日報(bào), 您本月的賬單已生成);代碼跑了之后輸出看起來應(yīng)該是短信發(fā)送至網(wǎng)關(guān) https://sms.example.com/send【加急】服務(wù)器告警 - CPU使用率超過90% 已觸發(fā)加急補(bǔ)救邏輯 站內(nèi)信發(fā)送賬單日報(bào) - 您本月的賬單已生成項(xiàng)目里后續(xù)要新增“語音通知”形態(tài)只需要擴(kuò)展抽象化做一個(gè)VoiceNotifier要新增“郵件渠道”只需要實(shí)現(xiàn)MessageSender接口做一個(gè)EmailSender。兩端互不干擾這就是橋接模式在業(yè)務(wù)系統(tǒng)里的真實(shí)收益。3.3 為什么橋接模式本質(zhì)是“組合優(yōu)于繼承”這一小節(jié)把原理層面的“為什么”徹底說透。橋接模式的核心機(jī)制不是接口定義得多漂亮而是用組合關(guān)系替代了多重繼承關(guān)系。面向?qū)ο蟮慕炭茣薪?jīng)常講組合優(yōu)于繼承但很多人只記住“組合”兩個(gè)字不理解底層的意圖。繼承是一種“靜態(tài)綁定”的關(guān)系子類在編譯期就確定了父類的類型和行為以后想換一個(gè)父類實(shí)現(xiàn)必須新增子類。組合是一種“動(dòng)態(tài)綁定”的關(guān)系持有的是接口引用運(yùn)行時(shí)可以傳入任何實(shí)現(xiàn)了這個(gè)接口的具體對象替換成本極低。橋接模式對組合的運(yùn)用比普通對象組合更進(jìn)一層。它不僅僅是“一個(gè)對象持有另一個(gè)服務(wù)對象”而是把“抽象維度”和“實(shí)現(xiàn)維度”分別設(shè)計(jì)成獨(dú)立的類層次然后通過接口引用把它們連接起來。這樣一來兩個(gè)維度都能獨(dú)立擴(kuò)展不會(huì)因?yàn)橐环降淖兓瘜?dǎo)致另一方的類體系產(chǎn)生連鎖改動(dòng)。用依賴倒置的原則看抽象化遙控器依賴的是實(shí)現(xiàn)化接口Device而不是具體實(shí)現(xiàn)化類電視、收音機(jī)。依賴關(guān)系停留在抽象層具體的組合在運(yùn)行期完成。這正好讓橋接模式在大型系統(tǒng)中成為處理平臺(tái)差異性的利器——業(yè)務(wù)側(cè)只依賴平臺(tái)抽象平臺(tái)側(cè)只關(guān)注底層實(shí)現(xiàn)互不越界。4. 橋接模式的典型應(yīng)用場景盤點(diǎn)4.1 GUI框架中的窗口與渲染引擎寫過桌面應(yīng)用或用過圖形庫的同學(xué)應(yīng)該都有印象UI控件的體系通常都特別龐大。按鈕、輸入框、下拉框、表格是一套繼承體系每個(gè)控件在不同操作系統(tǒng)上的渲染方式又不一樣。如果把“控件類型”和“渲染風(fēng)格”揉進(jìn)同一個(gè)繼承體系類數(shù)量會(huì)呈幾何級(jí)爆炸。橋接模式在這里的表現(xiàn)形態(tài)是控件體系屬于抽象化維度提供Button、Input、Table這類高層接口渲染引擎屬于實(shí)現(xiàn)化維度提供繪制API的抽象各個(gè)平臺(tái)的實(shí)現(xiàn)類負(fù)責(zé)真正調(diào)用底層圖形接口。新做一套換膚主題只需要新增一套渲染實(shí)現(xiàn)新增一種復(fù)雜控件只需要擴(kuò)展控件類兩邊的變化互不干擾。4.2 跨平臺(tái)多媒體與設(shè)備抽象再舉個(gè)硬核的例子跨平臺(tái)的多媒體播放框架。播放器的“行為層”包括播放、暫停、跳轉(zhuǎn)、倍速這些邏輯相對穩(wěn)定但底層對接的媒體后端差別很大有的后端是本地解碼器有的是流媒體服務(wù)器有的只支持特定格式。行為層和媒體后端之間的差異如果不拆開寫出來的播放器通常就是一坨難以維護(hù)的類集合。當(dāng)年我第一次看某跨平臺(tái)播放器的源碼時(shí)被震撼到的就是這層設(shè)計(jì)——播放器外層是純粹的狀態(tài)機(jī)和交互邏輯底層通過一個(gè)抽象的設(shè)備適配接口跟具體平臺(tái)對接新增一種平臺(tái)只需要實(shí)現(xiàn)一個(gè)后端適配器完全不需要?jiǎng)硬シ牌骱诵倪壿嫛＿@算是橋接模式在真實(shí)大型項(xiàng)目里相當(dāng)教科書級(jí)別的應(yīng)用。4.3 數(shù)據(jù)庫驅(qū)動(dòng)與連接協(xié)議的解耦你每次用某數(shù)據(jù)庫驅(qū)動(dòng)框架連接數(shù)據(jù)庫的時(shí)候其實(shí)都在無意識(shí)地使用橋接模式的變體。驅(qū)動(dòng)框架對外暴露的API屬于抽象化維度例如Connection接口、Statement接口而底層數(shù)據(jù)庫通信協(xié)議、網(wǎng)絡(luò)連接管理屬于實(shí)現(xiàn)化維度?？蚣軆?nèi)部通過組合關(guān)系把這兩層連接起來上層API和底層協(xié)議各自演進(jìn)彼此互不阻塞。判斷依據(jù)也很簡單數(shù)據(jù)庫產(chǎn)品增加一個(gè)新能力驅(qū)動(dòng)API可能完全不需要改上層應(yīng)用如果要新增一種數(shù)據(jù)庫類型它也只需要引入對應(yīng)的驅(qū)動(dòng)實(shí)現(xiàn)不需要改動(dòng)框架抽象。兩個(gè)維度都獨(dú)立變化這是橋接模式的典型指紋。4.4 消息推送系統(tǒng)的實(shí)戰(zhàn)復(fù)盤再回到我實(shí)際做過的推送系統(tǒng)案例。改造之前的系統(tǒng)結(jié)構(gòu)混亂到什么程度每新增一個(gè)推送渠道就要去改消息的各個(gè)形態(tài)類加if分支或新增子類代碼慢慢變成一鍋粥。后來我按橋接模式把結(jié)構(gòu)調(diào)整成“消息形態(tài)一條繼承鏈、發(fā)送渠道一條繼承鏈、中間用組合關(guān)聯(lián)”后續(xù)新增渠道的成本從“改三個(gè)類”降低到“新寫一個(gè)實(shí)現(xiàn)類”回歸測試的范圍也大大縮小。還有一個(gè)工程細(xì)節(jié)值得分享橋接模式改造后單元測試反而更好寫了。測試消息形態(tài)時(shí)只需要mock一個(gè)MessageSender的假實(shí)現(xiàn)測試渠道邏輯時(shí)用一個(gè)假的Notifier去觸發(fā)真實(shí)的Sender。兩端的測試完全解耦不用再為了測一個(gè)通知邏輯去準(zhǔn)備一堆依賴。5. 橋接、適配器、策略——模式辨析與避坑指南5.1 橋接 vs 適配器出發(fā)點(diǎn)完全不同“橋接”和“適配器”這兩個(gè)名字本身就造成了大量混淆。很多開發(fā)者一看到“把兩個(gè)東西接起來”就覺得是適配器一看到“組合一個(gè)接口”就覺得是橋接結(jié)果在系統(tǒng)設(shè)計(jì)時(shí)用錯(cuò)了模式。適配器模式解決的是“接口不兼容”的問題你手里有一個(gè)已經(jīng)存在的類它的方法簽名和系統(tǒng)期望的接口簽名對不上適配器包一層轉(zhuǎn)換邏輯讓兩邊能協(xié)作。它通常出現(xiàn)在系統(tǒng)集成階段強(qiáng)調(diào)“事后補(bǔ)救”。橋接模式解決的是“維度獨(dú)立變化”的問題它是在設(shè)計(jì)階段預(yù)先規(guī)劃好的結(jié)構(gòu)強(qiáng)調(diào)“事前設(shè)計(jì)”。舉個(gè)例子系統(tǒng)里已經(jīng)有一個(gè)叫MessageSender的具體類它有一個(gè)send(title, content)方法但系統(tǒng)需要一個(gè)sendMessage(MessagePayload)接口這時(shí)候?qū)懸粋€(gè)Adapter把舊類的調(diào)用包進(jìn)去這是適配器。而整套消息形態(tài)繼承鏈加渠道實(shí)現(xiàn)鏈加組合引用這是橋接。前者解決“怎么立刻用起來”后者解決“以后怎么長期擴(kuò)展”。5.2 橋接 vs 策略關(guān)注的對象不同策略模式的核心思想是“算法家族的封裝與切換”它把一組可替換的算法分別封裝成類然后在運(yùn)行時(shí)動(dòng)態(tài)選擇。策略模式關(guān)注的是“行為算法”的可替換性比如排序算法選快排還是歸并壓縮算法選GZIP還是ZIP。橋接模式關(guān)注的是“兩個(gè)獨(dú)立維度的結(jié)構(gòu)解耦”它關(guān)心的是抽象化的操作層和實(shí)現(xiàn)化的平臺(tái)層之間的長期演進(jìn)關(guān)系。遙控器場景里音量調(diào)節(jié)的“步長”確實(shí)有一點(diǎn)策略的意味但整體結(jié)構(gòu)的目標(biāo)是讓遙控器產(chǎn)品線和設(shè)備產(chǎn)品線各自獨(dú)立生長這個(gè)目標(biāo)和策略模式完全不同。區(qū)分的實(shí)用技巧是看變化方向策略模式的算法替換通常是“同維度內(nèi)的水平切換”橋接模式的兩個(gè)維度是兩個(gè)相互正交的變化軸。5.3 一套實(shí)操判斷標(biāo)準(zhǔn)綜合以上辨析我在實(shí)際項(xiàng)目里判斷是否使用橋接模式會(huì)依次問自己四個(gè)問題系統(tǒng)里是否存在兩個(gè)或兩個(gè)以上獨(dú)立變化的維度例如消息的形態(tài)和渠道、UI控件和渲染平臺(tái)這些維度是否都擁有或可能演化出多個(gè)變體使用繼承方式時(shí)類的數(shù)量是否正在逼近“乘法爆炸”這組維度在未來三個(gè)月內(nèi)是否有獨(dú)立的擴(kuò)展計(jì)劃如果四個(gè)問題答案都是“是”基本可以確定橋接模式是合適的。如果只有單一維度在變化或者擴(kuò)展的方向主要是水平加行為相同維度內(nèi)新增算法那優(yōu)先考慮策略模式如果是引入外部接口以兼容老系統(tǒng)那應(yīng)該用適配器模式。模式本身沒有高低之分用錯(cuò)位置才是真正的問題。橋接模式的價(jià)值是在“多維度變化”的結(jié)構(gòu)場景里發(fā)揮的如果你在單一維度的簡單場景里套用橋接反而會(huì)增加類數(shù)量和維護(hù)成本得不償失。6. 常見誤用與坑點(diǎn)實(shí)錄6.1 誤用一:把橋接模式當(dāng)“萬能膠水”每處組合都硬套有些同學(xué)看了橋接模式的類圖后發(fā)現(xiàn)在任何類組合的情景里都能套出“抽象化 實(shí)現(xiàn)化”的影子于是到處使用橋接模式。最終結(jié)果是原本幾個(gè)類就能說清楚的邏輯硬生生拆出十幾條繼承鏈和接口代碼復(fù)雜度飆升。橋接模式的適用前提是“存在兩個(gè)以上獨(dú)立變化的維度”。如果只是簡單的依賴注入、模塊解耦用普通組合或者接口隔離就夠了。我自己踩過的一次坑是在一個(gè)權(quán)限校驗(yàn)?zāi)K里套用了橋接模式把“用戶類型”和“校驗(yàn)策略”拆成兩套體系結(jié)果發(fā)現(xiàn)用戶類型和校驗(yàn)策略本來就是強(qiáng)耦合的根本不存在獨(dú)立變化的可能最終不得不又改回來。6.2 誤用二沒有識(shí)別出“真正的獨(dú)立維度”還有一種常見錯(cuò)誤是識(shí)別錯(cuò)了維度。拿電商系統(tǒng)的訂單處理來舉例有些人會(huì)把“訂單狀態(tài)”和“支付方式”當(dāng)作兩個(gè)獨(dú)立維度用橋接模式拆分但實(shí)際上訂單狀態(tài)的流轉(zhuǎn)邏輯對支付方式有強(qiáng)依賴——不同支付方式的回調(diào)語義完全不同把它們拆開會(huì)導(dǎo)致狀態(tài)機(jī)代碼里到處都是instanceof判斷反而比類爆炸更糟糕。識(shí)別維度的關(guān)鍵在于觀察變化方向是否“正交”一個(gè)維度變化時(shí)另一個(gè)維度是否完全不需要跟著變拿遙控器場景驗(yàn)證一下新增設(shè)備類Radio時(shí)遙控器抽象類和它所有子類都不需要改動(dòng)新增高級(jí)遙控器時(shí)設(shè)備接口和現(xiàn)有設(shè)備實(shí)現(xiàn)也不受影響。能通過這個(gè)驗(yàn)證才能認(rèn)定兩個(gè)維度是正交的。6.3 坑點(diǎn)橋接模式用上了但沒有守住抽象邊界即使正確識(shí)別了維度實(shí)際編碼過程中也容易破壞邊界。典型現(xiàn)象是抽象化類里出現(xiàn)平臺(tái)相關(guān)的判斷邏輯比如在RemoteControl里寫if (device instanceof Television)或者消息通知器里直接new SmsSender而不使用注入的引用。這些都是破壞橋接結(jié)構(gòu)的信號(hào)。守住邊界不是一句空話抽象化只能依賴實(shí)現(xiàn)化接口不能依賴任何具體實(shí)現(xiàn)化實(shí)現(xiàn)化接口的方法應(yīng)該是原子化的底層動(dòng)作不能暴露高層業(yè)務(wù)邏輯。守住這兩條橋接模式的好處才能發(fā)揮出來。我在Code Review里就經(jīng)常抓這兩條算是最具操作性的檢查清單。6.4 關(guān)于三方的速查對照我把幾個(gè)容易混淆的模式整理成了速查表方便你在設(shè)計(jì)時(shí)快速對照模式解決問題核心機(jī)制判斷標(biāo)志橋接模式抽象與實(shí)現(xiàn)維度獨(dú)立變化兩套繼承體系 組合關(guān)聯(lián)存在兩個(gè)獨(dú)立變化的維度類數(shù)量乘法膨脹適配器模式新舊接口不兼容集成遺留系統(tǒng)包一層中轉(zhuǎn)類有一個(gè)現(xiàn)成但不符合期望簽名的類策略模式同維度內(nèi)算法可替換接口 策略類集合 上下文行為算法經(jīng)常切換但骨架不變裝飾器模式動(dòng)態(tài)增強(qiáng)對象功能包裝器遞歸組合功能層層疊加不想生成子類這幾種模式有時(shí)會(huì)同時(shí)出現(xiàn)在同一套系統(tǒng)里不一定非要二選一。比如消息推送系統(tǒng)里橋接模式負(fù)責(zé)整體結(jié)構(gòu)渠道內(nèi)部的限流算法可以用策略模式對接老系統(tǒng)的接口可以用適配器——關(guān)鍵是在每個(gè)局部選擇最匹配的工具而不是一上來就套一個(gè)大而全的模式組合。7. 實(shí)戰(zhàn)心得與擴(kuò)展方向7.1 我什么時(shí)候會(huì)真正使用橋接模式寫代碼這些年我發(fā)現(xiàn)自己使用橋接模式的頻率并不高但每次都用在刀刃上。頻率不高的原因很簡單大部分業(yè)務(wù)系統(tǒng)的變化維度是模糊的或者在早期階段根本看不出來。但我一旦在需求中看到類似“支持多種XXX方式”并且這個(gè)XXX還允許跟另一個(gè)維度自由組合時(shí)就會(huì)立刻警覺起來。印象最深的一次是在做某跨平臺(tái)上傳組件時(shí)產(chǎn)品提出要支持本地存儲(chǔ)、分布式存儲(chǔ)、云存儲(chǔ)三類后端同時(shí)上傳過程要支持普通、分片、斷點(diǎn)續(xù)傳三種模式。當(dāng)時(shí)如果按繼承寫三乘三就是九個(gè)類而用橋接模式三個(gè)上傳形態(tài)類加三個(gè)存儲(chǔ)協(xié)議類就覆蓋了所有排列組合。后來產(chǎn)品真加了第四種存儲(chǔ)后端時(shí)我只需要新增一個(gè)存儲(chǔ)實(shí)現(xiàn)類其余代碼一行沒改。7.2 橋接模式后續(xù)可以怎么擴(kuò)展如果已經(jīng)用了橋接模式后續(xù)的演進(jìn)路徑通常很有意思。最直接的擴(kuò)展是“加入工廠模式”。兩個(gè)維度的組合如果很多調(diào)用方自己new各種組合的代碼就會(huì)很零散這時(shí)候可以引入工廠來封裝組合邏輯比如提供一個(gè)NotifierFactory根據(jù)參數(shù)返回合適的Notifier和Sender組合。另一個(gè)常見擴(kuò)展是結(jié)合“觀察者模式”。在消息推送系統(tǒng)里發(fā)送成功或失敗的事件可以被通知給外部監(jiān)聽器這個(gè)事件通知機(jī)制和橋接結(jié)構(gòu)可以很自然地共存——Notifier在調(diào)用Sender之后向外廣播事件Sender的替換不需要通知機(jī)制做任何改動(dòng)。還有一類擴(kuò)展是把橋梁的下游接到更抽象的領(lǐng)域。比如從消息推送推廣到“所有需要按多種方式交付的業(yè)務(wù)動(dòng)作”像工單系統(tǒng)里通知、轉(zhuǎn)派、升級(jí)、關(guān)閉各自對應(yīng)不同的渠道和策略同樣可以沿用橋接結(jié)構(gòu)?？傊畼蚪幽Ｊ降暮诵膬r(jià)值不在某一個(gè)具體的應(yīng)用而在于它為系統(tǒng)預(yù)留了結(jié)構(gòu)調(diào)整的空間。7.3 一點(diǎn)個(gè)人心得說點(diǎn)掏心窩的話設(shè)計(jì)模式學(xué)到最后拼的不是記住多少模式的類圖而是面對真實(shí)業(yè)務(wù)場景的時(shí)候能不能快速判斷出“結(jié)構(gòu)上該往哪個(gè)方向設(shè)計(jì)”。橋接模式對我來說是一種思維工具它提醒我在建模時(shí)永遠(yuǎn)先找“變化的維度”再?zèng)Q定用什么結(jié)構(gòu)去迎接這些變化。如果你正在學(xué)橋接模式建議別急著手?jǐn)]代碼先拿幾個(gè)自己寫過的項(xiàng)目復(fù)盤一下哪些地方因?yàn)轭惐ǘ纯噙^哪些地方因?yàn)榧有鹿δ芤膭?dòng)多個(gè)文件而煩躁過。找到那些“痛點(diǎn)”再去想橋接模式能不能治標(biāo)治本。這樣學(xué)到的模式才是長在自己身上的能力而不是背了一堆用不上的概念。 橋接模式實(shí)戰(zhàn)：用組合替代繼承，破解業(yè)務(wù)代碼類爆炸困境
寫了好幾年的業(yè)務(wù)代碼我越來越覺得設(shè)計(jì)模式這東西不是用來“背”的而是用來“救火”的。今天就聊一個(gè)我實(shí)際項(xiàng)目里反復(fù)用到的結(jié)構(gòu)型模式——橋接模式Bridge Pattern。先看一個(gè)我在真實(shí)開發(fā)中遇到的場景。某次接到一個(gè)需求要做一套跨平臺(tái)的文件上傳組件形態(tài)上要支持普通上傳、分片上傳、斷點(diǎn)續(xù)傳三種類型底層傳輸協(xié)議又要同時(shí)兼容HTTP、FTP、本地存儲(chǔ)三種方式。如果按傳統(tǒng)繼承思路去寫接口設(shè)計(jì)會(huì)直接變成三乘三等于九個(gè)實(shí)現(xiàn)類如果后續(xù)再加一種新的傳輸協(xié)議就得新增三個(gè)實(shí)現(xiàn)類改動(dòng)面很大。這正是橋接模式最典型的應(yīng)用時(shí)機(jī)——當(dāng)某個(gè)維度在獨(dú)立變化時(shí)用組合替代繼承把兩個(gè)維度的變化徹底解耦。這篇內(nèi)容我會(huì)拆開講透橋接模式的核心思想、四類角色、代碼實(shí)現(xiàn)和實(shí)戰(zhàn)中的判斷標(biāo)準(zhǔn)尤其會(huì)把“什么時(shí)候用橋接、什么時(shí)候別用橋接”講清楚因?yàn)檫@是我見過最多人踩坑的地方。無論你是剛學(xué)設(shè)計(jì)模式的新手還是寫了好幾年業(yè)務(wù)代碼但總覺得模式“用不上”的同學(xué)這篇應(yīng)該都能給你一些啟發(fā)。1. 橋接模式到底在解決什么問題1.1 繼承帶來的“類爆炸”困境我們先看繼承為什么會(huì)出問題。假設(shè)你要設(shè)計(jì)一套消息推送系統(tǒng)消息的展示形態(tài)有普通消息、加急消息、定時(shí)消息三種消息的發(fā)送渠道又有站內(nèi)信、短信、IM平臺(tái)三種。用繼承的思路你會(huì)先定義一個(gè)抽象的消息基類然后為每一種“形態(tài) 渠道”的組合創(chuàng)建一個(gè)子類于是得到九個(gè)類UrgentInAppMessage UrgentSmsMessage UrgentImMessage ScheduledInAppMessage ScheduledSmsMessage ScheduledImMessage NormalInAppMessage NormalSmsMessage NormalImMessage這些類的名字本身就暴露了問題命名里同時(shí)出現(xiàn)兩個(gè)維度的特征說明兩個(gè)維度的變化被強(qiáng)行綁死在繼承體系里了。如果以后要新增一個(gè)“語音消息”形態(tài)就得再寫三個(gè)子類類數(shù)量呈乘法增長每新增一個(gè)維度整個(gè)繼承樹的高度和廣度都跟著膨脹。這種寫法的核心矛盾在于兩個(gè)并不相關(guān)的變化因素被迫耦合在了一起。消息的“形態(tài)變化”和“渠道變化”本質(zhì)上是可以獨(dú)立演進(jìn)的但繼承把它們捆綁成一個(gè)整體任何一端的改動(dòng)都會(huì)波及整個(gè)類的集合。代碼量的膨脹還是小事真正的麻煩在于維護(hù)成本——你很難在九個(gè)幾乎長得差不多的類里精準(zhǔn)修改某一段邏輯也很難在測試時(shí)覆蓋所有組合。1.2 組合優(yōu)先把乘法換成加法橋接模式的處理思路就完全不同了。它把“形態(tài)”和“渠道”抽象成兩個(gè)獨(dú)立的結(jié)構(gòu)然后用組合的方式把它們連接起來。還是消息推送這個(gè)場景調(diào)整后的類結(jié)構(gòu)是這樣的一個(gè)消息抽象類包含形態(tài)邏輯內(nèi)部持有發(fā)送渠道的引用三個(gè)形態(tài)子類普通、加急、定時(shí)各自實(shí)現(xiàn)自己的業(yè)務(wù)邏輯三個(gè)發(fā)送渠道實(shí)現(xiàn)類站內(nèi)信、短信、IM平臺(tái)各自實(shí)現(xiàn)發(fā)送協(xié)議。這時(shí)候類數(shù)量是“三個(gè)形態(tài) 三個(gè)渠道 六個(gè)類”。形態(tài)新增一種類數(shù)量變成“四加三等于七個(gè)”渠道新增一種類數(shù)量變成“三加四等于七個(gè)”。組合總數(shù)在增加但類的數(shù)量始終是相加關(guān)系而不是相乘關(guān)系。這個(gè)加法和乘法的區(qū)別就是橋接模式最底層的價(jià)值。你仔細(xì)想想一個(gè)系統(tǒng)里如果存在M個(gè)“抽象化”變體和N個(gè)“實(shí)現(xiàn)化”變體用繼承體系需要M乘N個(gè)類橋接模式只需要M加N個(gè)類加一個(gè)組合引用。系統(tǒng)越復(fù)雜、維度越多這種結(jié)構(gòu)優(yōu)勢就越明顯。1.3 為什么不是簡單的“接口隔離”有同學(xué)可能會(huì)問我把接口定義好每個(gè)實(shí)現(xiàn)類里都注入一個(gè)渠道對象這不就是組合嗎和橋接模式有什么關(guān)系這是個(gè)好問題。普通組合強(qiáng)調(diào)的是“對象內(nèi)部持有一個(gè)服務(wù)對象”例如一個(gè)業(yè)務(wù)服務(wù)里注入一個(gè)數(shù)據(jù)庫操作類。但橋接模式更進(jìn)一步它強(qiáng)調(diào)的是抽象部分和實(shí)現(xiàn)部分各自擁有一套獨(dú)立的繼承體系并且這兩個(gè)體系都允許獨(dú)立擴(kuò)展。換句話說橋接模式是一種“有意識(shí)的、結(jié)構(gòu)化的組合”它要求你在設(shè)計(jì)之初就識(shí)別出兩個(gè)變化維度然后分別為它們建立抽象邊界最后通過組合把它們橋接起來。光在代碼里使用接口和組合不代表就是橋接模式——那只是面向?qū)ο笤O(shè)計(jì)的基本功。橋接模式的判別標(biāo)準(zhǔn)是是否存在兩條可以獨(dú)立變化的繼承鏈以及它們之間是否通過組合關(guān)聯(lián)。這個(gè)標(biāo)準(zhǔn)后面我會(huì)反復(fù)提到因?yàn)樗菂^(qū)分橋接模式和其他模式的關(guān)鍵。2. 橋接模式的核心角色與場景建模2.1 經(jīng)典場景遙控器與設(shè)備講解橋接模式繞不開一個(gè)經(jīng)典例子——遙控器和電器設(shè)備。這個(gè)例子的巧妙之處就在于它天然具備兩個(gè)獨(dú)立的變化維度遙控器設(shè)備端遙控器本身的形態(tài)和功能、控制端設(shè)備本身的種類和協(xié)議。想象你是某家電廠商的軟件負(fù)責(zé)人。你負(fù)責(zé)的遙控器產(chǎn)品線有基礎(chǔ)版和高級(jí)版兩種基礎(chǔ)版支持開關(guān)機(jī)和音量調(diào)節(jié)高級(jí)版額外支持靜音和語音控制?？刂频脑O(shè)備有電視和收音機(jī)兩種它們的開機(jī)邏輯、音量調(diào)節(jié)方式完全不同甚至通信協(xié)議都不一樣。如果用繼承實(shí)現(xiàn)類圖會(huì)是這樣的形狀先定義一個(gè)遙控器基類再分別派生出基礎(chǔ)遙控器-電視、基礎(chǔ)遙控器-收音機(jī)、高級(jí)遙控器-電視、高級(jí)遙控器-收音機(jī)四個(gè)具體類。哪怕遙控器外形只增加一個(gè)“極簡版”設(shè)備列表再增加一個(gè)“投影儀”類數(shù)量就會(huì)從四個(gè)變成九個(gè)。而橋接模式的處理方式是把遙控器和設(shè)備拆成兩套獨(dú)立的繼承鏈遙控器這一側(cè)抽象化的遙控器基類RemoteControl、基礎(chǔ)遙控器BasicRemoteControl、高級(jí)遙控器AdvancedRemoteControl設(shè)備這一側(cè)實(shí)現(xiàn)化的設(shè)備接口Device、電視Television、收音機(jī)Radio遙控器內(nèi)部持有一個(gè)設(shè)備引用組合關(guān)系在這里建立。以后遙控器產(chǎn)品線隨便加新品設(shè)備產(chǎn)品線隨便加設(shè)備彼此互不干擾數(shù)量始終是加法關(guān)系。這就是橋接模式設(shè)計(jì)的核心形態(tài)——兩棵獨(dú)立的“樹”之間通過一個(gè)組合引用搭起橋。2.2 四類角色逐一拆解橋接模式的官方命名體系里有四類經(jīng)典角色理解它們是掌握這個(gè)模式的關(guān)鍵抽象化Abstraction抽象化定義的是“控制方”的抽象接口。以遙控器場景為例RemoteControl就是抽象化角色。它內(nèi)部持有一個(gè)實(shí)現(xiàn)化的引用Device并把用戶可感知的高層操作開關(guān)機(jī)、音量加減定義為接口。需要注意的是抽象化里通常會(huì)維護(hù)一個(gè)成員變量這個(gè)成員變量的類型是“實(shí)現(xiàn)化接口”而不是某個(gè)具體實(shí)現(xiàn)類。擴(kuò)展抽象化RefinedAbstraction擴(kuò)展抽象化是抽象化接口的子類。例如BasicRemoteControl和AdvancedRemoteControl就是兩個(gè)擴(kuò)展抽象化。它們可以改變高層操作的具體邏輯也可以增加新的高層操作比如高級(jí)版的靜音功能但都不需要關(guān)心底層設(shè)備如何執(zhí)行這些操作。實(shí)現(xiàn)化Implementor實(shí)現(xiàn)化定義的是“被控制方”的底層操作接口。本例中的Device就是實(shí)現(xiàn)化接口它聲明了turnOn、turnOff、setVolume這類底層動(dòng)作。這些動(dòng)作是相對原子化的通常一個(gè)動(dòng)作對應(yīng)一個(gè)最基本的硬件操作或協(xié)議指令。具體實(shí)現(xiàn)化ConcreteImplementor具體實(shí)現(xiàn)化是實(shí)現(xiàn)化接口的具體類例如Television和Radio。每個(gè)具體實(shí)現(xiàn)化類都要完整實(shí)現(xiàn)設(shè)備接口定義的所有底層操作并依據(jù)自身硬件特性決定執(zhí)行細(xì)節(jié)。你可能會(huì)覺得這套命名有點(diǎn)抽象。換個(gè)角度記抽象化 用戶能看到的操作層實(shí)現(xiàn)化 底層平臺(tái)的具體執(zhí)行層擴(kuò)展抽象化 操作層的不同款式具體實(shí)現(xiàn)化 平臺(tái)層的不同產(chǎn)品。2.3 關(guān)鍵設(shè)計(jì)決策誰握著誰的引用橋接模式里最容易搞反的一個(gè)問題就是引用的方向。正確的做法是抽象化持有實(shí)現(xiàn)化的引用而不是反過來。也就是說RemoteControl內(nèi)部存在一個(gè)Device類型的字段創(chuàng)建遙控器時(shí)通過構(gòu)造器把具體的設(shè)備傳進(jìn)去。這個(gè)方向?yàn)槭裁床荒芊匆驗(yàn)閺臉I(yè)務(wù)流程看遙控器是“發(fā)起動(dòng)作的一方”設(shè)備是“接收動(dòng)作并執(zhí)行的一方”。遙控器需要知道自己在控制什么設(shè)備從而調(diào)用對應(yīng)設(shè)備的方法反過來設(shè)備完全不需要知道是誰在控制自己——電視不會(huì)因?yàn)檫b控器掛了就沒法開機(jī)內(nèi)置的物理按鍵同樣能開機(jī)。從依賴關(guān)系的角度看抽象化依賴實(shí)現(xiàn)化接口正好符合依賴倒置原則高層模塊遙控器不依賴低層模塊具體設(shè)備而是依賴抽象Device接口。如果反將其道讓設(shè)備持有遙控器的引用就會(huì)出現(xiàn)一種毫無道理的逆向依賴——設(shè)備要“知道”遙控器如何操作自己這對設(shè)備的獨(dú)立復(fù)用是一種破壞也違背了橋接模式解耦的初衷。3. 代碼實(shí)現(xiàn)從Java到TypeScript的完整落地3.1 Java實(shí)現(xiàn)遙控器與設(shè)備的經(jīng)典搭配橋接模式最常見的學(xué)習(xí)語言是Java我們先把完整流程寫一遍。首先是實(shí)現(xiàn)化接口也就是Device/** * 實(shí)現(xiàn)化接口設(shè)備 */ public interface Device { void turnOn(); void turnOff(); void setVolume(int percent); int getVolume(); boolean isEnabled(); }接著是兩個(gè)具體實(shí)現(xiàn)化類電視機(jī)和收音機(jī)/** * 具體實(shí)現(xiàn)化電視機(jī) */ public class Television implements Device { private boolean enabled false; private int volume 20; Override public void turnOn() { this.enabled true; System.out.println(電視機(jī)已開機(jī)); } Override public void turnOff() { this.enabled false; System.out.println(電視機(jī)已關(guān)機(jī)); } Override public void setVolume(int percent) { this.volume Math.max(0, Math.min(100, percent)); System.out.println(電視機(jī)音量設(shè)置為 this.volume); } Override public int getVolume() { return this.volume; } Override public boolean isEnabled() { return this.enabled; } }/** * 具體實(shí)現(xiàn)化收音機(jī) */ public class Radio implements Device { private boolean enabled false; private int volume 30; Override public void turnOn() { this.enabled true; System.out.println(收音機(jī)已開機(jī)); } Override public void turnOff() { this.enabled false; System.out.println(收音機(jī)已關(guān)機(jī)); } Override public void setVolume(int percent) { this.volume Math.max(0, Math.min(100, percent)); System.out.println(收音機(jī)音量設(shè)置為 this.volume); } Override public int getVolume() { return this.volume; } Override public boolean isEnabled() { return this.enabled; } }然后是抽象化角色RemoteControl。注意它的構(gòu)造器參數(shù)是Device接口而不是具體設(shè)備類這是組合關(guān)系成立的關(guān)鍵/** * 抽象化角色遙控器 */ public abstract class RemoteControl { protected Device device; public RemoteControl(Device device) { this.device device; } public abstract void togglePower(); public abstract void volumeUp(); public abstract void volumeDown(); }基礎(chǔ)遙控器和高級(jí)遙控器作為擴(kuò)展抽象化角色/** * 擴(kuò)展抽象化基礎(chǔ)遙控器 */ public class BasicRemoteControl extends RemoteControl { public BasicRemoteControl(Device device) { super(device); } Override public void togglePower() { System.out.println(基礎(chǔ)遙控器執(zhí)行開關(guān)機(jī)); if (device.isEnabled()) { device.turnOff(); } else { device.turnOn(); } } Override public void volumeUp() { device.setVolume(device.getVolume() 5); } Override public void volumeDown() { device.setVolume(device.getVolume() - 5); } }/** * 擴(kuò)展抽象化高級(jí)遙控器 */ public class AdvancedRemoteControl extends RemoteControl { public AdvancedRemoteControl(Device device) { super(device); } Override public void togglePower() { System.out.println(高級(jí)遙控器執(zhí)行開關(guān)機(jī)); if (device.isEnabled()) { device.turnOff(); } else { device.turnOn(); } } Override public void volumeUp() { device.setVolume(device.getVolume() 10); } Override public void volumeDown() { device.setVolume(device.getVolume() - 10); } // 高級(jí)遙控器獨(dú)有功能靜音 public void mute() { device.setVolume(0); System.out.println(已靜音); } }調(diào)用方測試代碼public class BridgePatternDemo { public static void main(String[] args) { Device tv new Television(); RemoteControl basicRemote new BasicRemoteControl(tv); basicRemote.togglePower(); basicRemote.volumeUp(); Device radio new Radio(); AdvancedRemoteControl advancedRemote new AdvancedRemoteControl(radio); advancedRemote.togglePower(); advancedRemote.mute(); } }這段代碼運(yùn)行后輸出如下基礎(chǔ)遙控器執(zhí)行開關(guān)機(jī) 電視機(jī)已開機(jī) 電視機(jī)音量設(shè)置為25假設(shè)初始音量20 高級(jí)遙控器執(zhí)行開關(guān)機(jī) 收音機(jī)已開機(jī) 已靜音 收音機(jī)音量設(shè)置為0觀察這段代碼你會(huì)發(fā)現(xiàn)一個(gè)細(xì)節(jié)BasicRemoteControl和AdvancedRemoteControl里的togglePower方法邏輯幾乎一樣只是標(biāo)識(shí)不同。這是我刻意保留的。兩種遙控器對“開關(guān)機(jī)”這個(gè)操作確實(shí)沒有本質(zhì)區(qū)別但它們在音量調(diào)節(jié)步進(jìn)和擴(kuò)展功能上有差異。真實(shí)項(xiàng)目里這種邏輯相近的情況很常見想要消除重復(fù)可以把公共邏輯上移到抽象化基類但要注意別因此把抽象化基類和實(shí)現(xiàn)化接口又捆死在一起。3.2 TypeScript實(shí)現(xiàn)企業(yè)級(jí)消息推送系統(tǒng)的橋接改造我們看一個(gè)更有現(xiàn)實(shí)感的場景——消息推送服務(wù)。這是我在工程中真正用橋接模式重構(gòu)過的項(xiàng)目類型比遙控器例子更接近業(yè)務(wù)系統(tǒng)。先看初始的問題代碼。假設(shè)系統(tǒng)里有“加急通知”和“定時(shí)通知”兩種消息形態(tài)每種形態(tài)都要能發(fā)到站內(nèi)信、短信、IM平臺(tái)三種渠道。常規(guī)寫法的類結(jié)構(gòu)是這樣的// 未使用橋接模式的錯(cuò)誤示范 class UrgentInAppNotifier { send(title: string, content: string): void { console.log(【站內(nèi)信】加急發(fā)送${title} - ${content}); } } class UrgentSmsNotifier { send(title: string, content: string): void { console.log(【短信】加急發(fā)送${title} - ${content}); } } class ScheduledImNotifier { send(title: string, content: string): void { console.log(【IM平臺(tái)】定時(shí)發(fā)送${title} - ${content}); } }如果照著這個(gè)路子寫九個(gè)類跑不掉。而且你看這個(gè)類命名形態(tài)和渠道倆維度攪在一起哪怕后面只加一種“語音通知形態(tài)”也要同時(shí)改三個(gè)類。用橋接模式重構(gòu)后首先定義渠道接口和三個(gè)渠道實(shí)現(xiàn)/** * 實(shí)現(xiàn)化接口消息發(fā)送渠道 */ export interface MessageSender { sendMessage(title: string, content: string, scheduleTime?: Date): Promiseboolean; } /** * 具體實(shí)現(xiàn)化站內(nèi)信渠道 */ export class InAppSender implements MessageSender { async sendMessage(title: string, content: string, scheduleTime?: Date): Promiseboolean { if (scheduleTime) { console.log(站內(nèi)信已定時(shí)將在 ${scheduleTime.toISOString()} 發(fā)送${title}); } else { console.log(站內(nèi)信發(fā)送${title} - ${content}); } return true; } } /** * 具體實(shí)現(xiàn)化短信渠道注意這里需要對接某短信服務(wù)商的HTTP接口 */ export class SmsSender implements MessageSender { private readonly endpoint: string; constructor(endpoint: string) { this.endpoint endpoint; } async sendMessage(title: string, content: string, scheduleTime?: Date): Promiseboolean { // 真實(shí)項(xiàng)目里這里會(huì)調(diào)用短信服務(wù)商的API并做簽名、限流、重試等處理 console.log(短信發(fā)送至網(wǎng)關(guān) ${this.endpoint}${title} - ${content}); return true; } } /** * 具體實(shí)現(xiàn)化IM平臺(tái)渠道 */ export class ImSender implements MessageSender { private readonly webhook: string; constructor(webhook: string) { this.webhook webhook; } async sendMessage(title: string, content: string, scheduleTime?: Date): Promiseboolean { console.log(IM平臺(tái)推送至 ${this.webhook}${title} - ${content}); return true; } }接著定義抽象化的通知器基類和兩種擴(kuò)展抽象化/** * 抽象化角色消息通知器 */ export abstract class MessageNotifier { protected sender: MessageSender; constructor(sender: MessageSender) { this.sender sender; } abstract notify(title: string, content: string): Promisevoid; } /** * 擴(kuò)展抽象化普通通知 */ export class NormalNotifier extends MessageNotifier { async notify(title: string, content: string): Promisevoid { await this.sender.sendMessage(title, content); } } /** * 擴(kuò)展抽象化加急通知 */ export class UrgentNotifier extends MessageNotifier { async notify(title: string, content: string): Promisevoid { // 加急通知通常會(huì)走優(yōu)先級(jí)更高的通道或追加短信作為兜底 await this.sender.sendMessage(【加急】${title}, content); console.log(已觸發(fā)加急補(bǔ)救邏輯); } }使用側(cè)代碼const inAppSender new InAppSender(); const smsSender new SmsSender(https://sms.example.com/send); const imSender new ImSender(https://im.example.com/webhook); // 加急通知走短信渠道 const urgentSms new UrgentNotifier(smsSender); await urgentSms.notify(服務(wù)器告警, CPU使用率超過90%); // 普通通知走站內(nèi)信渠道 const normalInApp new NormalNotifier(inAppSender); await normalInApp.notify(賬單日報(bào), 您本月的賬單已生成);代碼跑了之后輸出看起來應(yīng)該是短信發(fā)送至網(wǎng)關(guān) https://sms.example.com/send【加急】服務(wù)器告警 - CPU使用率超過90% 已觸發(fā)加急補(bǔ)救邏輯 站內(nèi)信發(fā)送賬單日報(bào) - 您本月的賬單已生成項(xiàng)目里后續(xù)要新增“語音通知”形態(tài)只需要擴(kuò)展抽象化做一個(gè)VoiceNotifier要新增“郵件渠道”只需要實(shí)現(xiàn)MessageSender接口做一個(gè)EmailSender。兩端互不干擾這就是橋接模式在業(yè)務(wù)系統(tǒng)里的真實(shí)收益。3.3 為什么橋接模式本質(zhì)是“組合優(yōu)于繼承”這一小節(jié)把原理層面的“為什么”徹底說透。橋接模式的核心機(jī)制不是接口定義得多漂亮而是用組合關(guān)系替代了多重繼承關(guān)系。面向?qū)ο蟮慕炭茣薪?jīng)常講組合優(yōu)于繼承但很多人只記住“組合”兩個(gè)字不理解底層的意圖。繼承是一種“靜態(tài)綁定”的關(guān)系子類在編譯期就確定了父類的類型和行為以后想換一個(gè)父類實(shí)現(xiàn)必須新增子類。組合是一種“動(dòng)態(tài)綁定”的關(guān)系持有的是接口引用運(yùn)行時(shí)可以傳入任何實(shí)現(xiàn)了這個(gè)接口的具體對象替換成本極低。橋接模式對組合的運(yùn)用比普通對象組合更進(jìn)一層。它不僅僅是“一個(gè)對象持有另一個(gè)服務(wù)對象”而是把“抽象維度”和“實(shí)現(xiàn)維度”分別設(shè)計(jì)成獨(dú)立的類層次然后通過接口引用把它們連接起來。這樣一來兩個(gè)維度都能獨(dú)立擴(kuò)展不會(huì)因?yàn)橐环降淖兓瘜?dǎo)致另一方的類體系產(chǎn)生連鎖改動(dòng)。用依賴倒置的原則看抽象化遙控器依賴的是實(shí)現(xiàn)化接口Device而不是具體實(shí)現(xiàn)化類電視、收音機(jī)。依賴關(guān)系停留在抽象層具體的組合在運(yùn)行期完成。這正好讓橋接模式在大型系統(tǒng)中成為處理平臺(tái)差異性的利器——業(yè)務(wù)側(cè)只依賴平臺(tái)抽象平臺(tái)側(cè)只關(guān)注底層實(shí)現(xiàn)互不越界。4. 橋接模式的典型應(yīng)用場景盤點(diǎn)4.1 GUI框架中的窗口與渲染引擎寫過桌面應(yīng)用或用過圖形庫的同學(xué)應(yīng)該都有印象UI控件的體系通常都特別龐大。按鈕、輸入框、下拉框、表格是一套繼承體系每個(gè)控件在不同操作系統(tǒng)上的渲染方式又不一樣。如果把“控件類型”和“渲染風(fēng)格”揉進(jìn)同一個(gè)繼承體系類數(shù)量會(huì)呈幾何級(jí)爆炸。橋接模式在這里的表現(xiàn)形態(tài)是控件體系屬于抽象化維度提供Button、Input、Table這類高層接口渲染引擎屬于實(shí)現(xiàn)化維度提供繪制API的抽象各個(gè)平臺(tái)的實(shí)現(xiàn)類負(fù)責(zé)真正調(diào)用底層圖形接口。新做一套換膚主題只需要新增一套渲染實(shí)現(xiàn)新增一種復(fù)雜控件只需要擴(kuò)展控件類兩邊的變化互不干擾。4.2 跨平臺(tái)多媒體與設(shè)備抽象再舉個(gè)硬核的例子跨平臺(tái)的多媒體播放框架。播放器的“行為層”包括播放、暫停、跳轉(zhuǎn)、倍速這些邏輯相對穩(wěn)定但底層對接的媒體后端差別很大有的后端是本地解碼器有的是流媒體服務(wù)器有的只支持特定格式。行為層和媒體后端之間的差異如果不拆開寫出來的播放器通常就是一坨難以維護(hù)的類集合。當(dāng)年我第一次看某跨平臺(tái)播放器的源碼時(shí)被震撼到的就是這層設(shè)計(jì)——播放器外層是純粹的狀態(tài)機(jī)和交互邏輯底層通過一個(gè)抽象的設(shè)備適配接口跟具體平臺(tái)對接新增一種平臺(tái)只需要實(shí)現(xiàn)一個(gè)后端適配器完全不需要?jiǎng)硬シ牌骱诵倪壿嫛＿@算是橋接模式在真實(shí)大型項(xiàng)目里相當(dāng)教科書級(jí)別的應(yīng)用。4.3 數(shù)據(jù)庫驅(qū)動(dòng)與連接協(xié)議的解耦你每次用某數(shù)據(jù)庫驅(qū)動(dòng)框架連接數(shù)據(jù)庫的時(shí)候其實(shí)都在無意識(shí)地使用橋接模式的變體。驅(qū)動(dòng)框架對外暴露的API屬于抽象化維度例如Connection接口、Statement接口而底層數(shù)據(jù)庫通信協(xié)議、網(wǎng)絡(luò)連接管理屬于實(shí)現(xiàn)化維度?？蚣軆?nèi)部通過組合關(guān)系把這兩層連接起來上層API和底層協(xié)議各自演進(jìn)彼此互不阻塞。判斷依據(jù)也很簡單數(shù)據(jù)庫產(chǎn)品增加一個(gè)新能力驅(qū)動(dòng)API可能完全不需要改上層應(yīng)用如果要新增一種數(shù)據(jù)庫類型它也只需要引入對應(yīng)的驅(qū)動(dòng)實(shí)現(xiàn)不需要改動(dòng)框架抽象。兩個(gè)維度都獨(dú)立變化這是橋接模式的典型指紋。4.4 消息推送系統(tǒng)的實(shí)戰(zhàn)復(fù)盤再回到我實(shí)際做過的推送系統(tǒng)案例。改造之前的系統(tǒng)結(jié)構(gòu)混亂到什么程度每新增一個(gè)推送渠道就要去改消息的各個(gè)形態(tài)類加if分支或新增子類代碼慢慢變成一鍋粥。后來我按橋接模式把結(jié)構(gòu)調(diào)整成“消息形態(tài)一條繼承鏈、發(fā)送渠道一條繼承鏈、中間用組合關(guān)聯(lián)”后續(xù)新增渠道的成本從“改三個(gè)類”降低到“新寫一個(gè)實(shí)現(xiàn)類”回歸測試的范圍也大大縮小。還有一個(gè)工程細(xì)節(jié)值得分享橋接模式改造后單元測試反而更好寫了。測試消息形態(tài)時(shí)只需要mock一個(gè)MessageSender的假實(shí)現(xiàn)測試渠道邏輯時(shí)用一個(gè)假的Notifier去觸發(fā)真實(shí)的Sender。兩端的測試完全解耦不用再為了測一個(gè)通知邏輯去準(zhǔn)備一堆依賴。5. 橋接、適配器、策略——模式辨析與避坑指南5.1 橋接 vs 適配器出發(fā)點(diǎn)完全不同“橋接”和“適配器”這兩個(gè)名字本身就造成了大量混淆。很多開發(fā)者一看到“把兩個(gè)東西接起來”就覺得是適配器一看到“組合一個(gè)接口”就覺得是橋接結(jié)果在系統(tǒng)設(shè)計(jì)時(shí)用錯(cuò)了模式。適配器模式解決的是“接口不兼容”的問題你手里有一個(gè)已經(jīng)存在的類它的方法簽名和系統(tǒng)期望的接口簽名對不上適配器包一層轉(zhuǎn)換邏輯讓兩邊能協(xié)作。它通常出現(xiàn)在系統(tǒng)集成階段強(qiáng)調(diào)“事后補(bǔ)救”。橋接模式解決的是“維度獨(dú)立變化”的問題它是在設(shè)計(jì)階段預(yù)先規(guī)劃好的結(jié)構(gòu)強(qiáng)調(diào)“事前設(shè)計(jì)”。舉個(gè)例子系統(tǒng)里已經(jīng)有一個(gè)叫MessageSender的具體類它有一個(gè)send(title, content)方法但系統(tǒng)需要一個(gè)sendMessage(MessagePayload)接口這時(shí)候?qū)懸粋€(gè)Adapter把舊類的調(diào)用包進(jìn)去這是適配器。而整套消息形態(tài)繼承鏈加渠道實(shí)現(xiàn)鏈加組合引用這是橋接。前者解決“怎么立刻用起來”后者解決“以后怎么長期擴(kuò)展”。5.2 橋接 vs 策略關(guān)注的對象不同策略模式的核心思想是“算法家族的封裝與切換”它把一組可替換的算法分別封裝成類然后在運(yùn)行時(shí)動(dòng)態(tài)選擇。策略模式關(guān)注的是“行為算法”的可替換性比如排序算法選快排還是歸并壓縮算法選GZIP還是ZIP。橋接模式關(guān)注的是“兩個(gè)獨(dú)立維度的結(jié)構(gòu)解耦”它關(guān)心的是抽象化的操作層和實(shí)現(xiàn)化的平臺(tái)層之間的長期演進(jìn)關(guān)系。遙控器場景里音量調(diào)節(jié)的“步長”確實(shí)有一點(diǎn)策略的意味但整體結(jié)構(gòu)的目標(biāo)是讓遙控器產(chǎn)品線和設(shè)備產(chǎn)品線各自獨(dú)立生長這個(gè)目標(biāo)和策略模式完全不同。區(qū)分的實(shí)用技巧是看變化方向策略模式的算法替換通常是“同維度內(nèi)的水平切換”橋接模式的兩個(gè)維度是兩個(gè)相互正交的變化軸。5.3 一套實(shí)操判斷標(biāo)準(zhǔn)綜合以上辨析我在實(shí)際項(xiàng)目里判斷是否使用橋接模式會(huì)依次問自己四個(gè)問題系統(tǒng)里是否存在兩個(gè)或兩個(gè)以上獨(dú)立變化的維度例如消息的形態(tài)和渠道、UI控件和渲染平臺(tái)這些維度是否都擁有或可能演化出多個(gè)變體使用繼承方式時(shí)類的數(shù)量是否正在逼近“乘法爆炸”這組維度在未來三個(gè)月內(nèi)是否有獨(dú)立的擴(kuò)展計(jì)劃如果四個(gè)問題答案都是“是”基本可以確定橋接模式是合適的。如果只有單一維度在變化或者擴(kuò)展的方向主要是水平加行為相同維度內(nèi)新增算法那優(yōu)先考慮策略模式如果是引入外部接口以兼容老系統(tǒng)那應(yīng)該用適配器模式。模式本身沒有高低之分用錯(cuò)位置才是真正的問題。橋接模式的價(jià)值是在“多維度變化”的結(jié)構(gòu)場景里發(fā)揮的如果你在單一維度的簡單場景里套用橋接反而會(huì)增加類數(shù)量和維護(hù)成本得不償失。6. 常見誤用與坑點(diǎn)實(shí)錄6.1 誤用一:把橋接模式當(dāng)“萬能膠水”每處組合都硬套有些同學(xué)看了橋接模式的類圖后發(fā)現(xiàn)在任何類組合的情景里都能套出“抽象化 實(shí)現(xiàn)化”的影子于是到處使用橋接模式。最終結(jié)果是原本幾個(gè)類就能說清楚的邏輯硬生生拆出十幾條繼承鏈和接口代碼復(fù)雜度飆升。橋接模式的適用前提是“存在兩個(gè)以上獨(dú)立變化的維度”。如果只是簡單的依賴注入、模塊解耦用普通組合或者接口隔離就夠了。我自己踩過的一次坑是在一個(gè)權(quán)限校驗(yàn)?zāi)K里套用了橋接模式把“用戶類型”和“校驗(yàn)策略”拆成兩套體系結(jié)果發(fā)現(xiàn)用戶類型和校驗(yàn)策略本來就是強(qiáng)耦合的根本不存在獨(dú)立變化的可能最終不得不又改回來。6.2 誤用二沒有識(shí)別出“真正的獨(dú)立維度”還有一種常見錯(cuò)誤是識(shí)別錯(cuò)了維度。拿電商系統(tǒng)的訂單處理來舉例有些人會(huì)把“訂單狀態(tài)”和“支付方式”當(dāng)作兩個(gè)獨(dú)立維度用橋接模式拆分但實(shí)際上訂單狀態(tài)的流轉(zhuǎn)邏輯對支付方式有強(qiáng)依賴——不同支付方式的回調(diào)語義完全不同把它們拆開會(huì)導(dǎo)致狀態(tài)機(jī)代碼里到處都是instanceof判斷反而比類爆炸更糟糕。識(shí)別維度的關(guān)鍵在于觀察變化方向是否“正交”一個(gè)維度變化時(shí)另一個(gè)維度是否完全不需要跟著變拿遙控器場景驗(yàn)證一下新增設(shè)備類Radio時(shí)遙控器抽象類和它所有子類都不需要改動(dòng)新增高級(jí)遙控器時(shí)設(shè)備接口和現(xiàn)有設(shè)備實(shí)現(xiàn)也不受影響。能通過這個(gè)驗(yàn)證才能認(rèn)定兩個(gè)維度是正交的。6.3 坑點(diǎn)橋接模式用上了但沒有守住抽象邊界即使正確識(shí)別了維度實(shí)際編碼過程中也容易破壞邊界。典型現(xiàn)象是抽象化類里出現(xiàn)平臺(tái)相關(guān)的判斷邏輯比如在RemoteControl里寫if (device instanceof Television)或者消息通知器里直接new SmsSender而不使用注入的引用。這些都是破壞橋接結(jié)構(gòu)的信號(hào)。守住邊界不是一句空話抽象化只能依賴實(shí)現(xiàn)化接口不能依賴任何具體實(shí)現(xiàn)化實(shí)現(xiàn)化接口的方法應(yīng)該是原子化的底層動(dòng)作不能暴露高層業(yè)務(wù)邏輯。守住這兩條橋接模式的好處才能發(fā)揮出來。我在Code Review里就經(jīng)常抓這兩條算是最具操作性的檢查清單。6.4 關(guān)于三方的速查對照我把幾個(gè)容易混淆的模式整理成了速查表方便你在設(shè)計(jì)時(shí)快速對照模式解決問題核心機(jī)制判斷標(biāo)志橋接模式抽象與實(shí)現(xiàn)維度獨(dú)立變化兩套繼承體系 組合關(guān)聯(lián)存在兩個(gè)獨(dú)立變化的維度類數(shù)量乘法膨脹適配器模式新舊接口不兼容集成遺留系統(tǒng)包一層中轉(zhuǎn)類有一個(gè)現(xiàn)成但不符合期望簽名的類策略模式同維度內(nèi)算法可替換接口 策略類集合 上下文行為算法經(jīng)常切換但骨架不變裝飾器模式動(dòng)態(tài)增強(qiáng)對象功能包裝器遞歸組合功能層層疊加不想生成子類這幾種模式有時(shí)會(huì)同時(shí)出現(xiàn)在同一套系統(tǒng)里不一定非要二選一。比如消息推送系統(tǒng)里橋接模式負(fù)責(zé)整體結(jié)構(gòu)渠道內(nèi)部的限流算法可以用策略模式對接老系統(tǒng)的接口可以用適配器——關(guān)鍵是在每個(gè)局部選擇最匹配的工具而不是一上來就套一個(gè)大而全的模式組合。7. 實(shí)戰(zhàn)心得與擴(kuò)展方向7.1 我什么時(shí)候會(huì)真正使用橋接模式寫代碼這些年我發(fā)現(xiàn)自己使用橋接模式的頻率并不高但每次都用在刀刃上。頻率不高的原因很簡單大部分業(yè)務(wù)系統(tǒng)的變化維度是模糊的或者在早期階段根本看不出來。但我一旦在需求中看到類似“支持多種XXX方式”并且這個(gè)XXX還允許跟另一個(gè)維度自由組合時(shí)就會(huì)立刻警覺起來。印象最深的一次是在做某跨平臺(tái)上傳組件時(shí)產(chǎn)品提出要支持本地存儲(chǔ)、分布式存儲(chǔ)、云存儲(chǔ)三類后端同時(shí)上傳過程要支持普通、分片、斷點(diǎn)續(xù)傳三種模式。當(dāng)時(shí)如果按繼承寫三乘三就是九個(gè)類而用橋接模式三個(gè)上傳形態(tài)類加三個(gè)存儲(chǔ)協(xié)議類就覆蓋了所有排列組合。后來產(chǎn)品真加了第四種存儲(chǔ)后端時(shí)我只需要新增一個(gè)存儲(chǔ)實(shí)現(xiàn)類其余代碼一行沒改。7.2 橋接模式后續(xù)可以怎么擴(kuò)展如果已經(jīng)用了橋接模式后續(xù)的演進(jìn)路徑通常很有意思。最直接的擴(kuò)展是“加入工廠模式”。兩個(gè)維度的組合如果很多調(diào)用方自己new各種組合的代碼就會(huì)很零散這時(shí)候可以引入工廠來封裝組合邏輯比如提供一個(gè)NotifierFactory根據(jù)參數(shù)返回合適的Notifier和Sender組合。另一個(gè)常見擴(kuò)展是結(jié)合“觀察者模式”。在消息推送系統(tǒng)里發(fā)送成功或失敗的事件可以被通知給外部監(jiān)聽器這個(gè)事件通知機(jī)制和橋接結(jié)構(gòu)可以很自然地共存——Notifier在調(diào)用Sender之后向外廣播事件Sender的替換不需要通知機(jī)制做任何改動(dòng)。還有一類擴(kuò)展是把橋梁的下游接到更抽象的領(lǐng)域。比如從消息推送推廣到“所有需要按多種方式交付的業(yè)務(wù)動(dòng)作”像工單系統(tǒng)里通知、轉(zhuǎn)派、升級(jí)、關(guān)閉各自對應(yīng)不同的渠道和策略同樣可以沿用橋接結(jié)構(gòu)?？傊畼蚪幽Ｊ降暮诵膬r(jià)值不在某一個(gè)具體的應(yīng)用而在于它為系統(tǒng)預(yù)留了結(jié)構(gòu)調(diào)整的空間。7.3 一點(diǎn)個(gè)人心得說點(diǎn)掏心窩的話設(shè)計(jì)模式學(xué)到最后拼的不是記住多少模式的類圖而是面對真實(shí)業(yè)務(wù)場景的時(shí)候能不能快速判斷出“結(jié)構(gòu)上該往哪個(gè)方向設(shè)計(jì)”。橋接模式對我來說是一種思維工具它提醒我在建模時(shí)永遠(yuǎn)先找“變化的維度”再?zèng)Q定用什么結(jié)構(gòu)去迎接這些變化。如果你正在學(xué)橋接模式建議別急著手?jǐn)]代碼先拿幾個(gè)自己寫過的項(xiàng)目復(fù)盤一下哪些地方因?yàn)轭惐ǘ纯噙^哪些地方因?yàn)榧有鹿δ芤膭?dòng)多個(gè)文件而煩躁過。找到那些“痛點(diǎn)”再去想橋接模式能不能治標(biāo)治本。這樣學(xué)到的模式才是長在自己身上的能力而不是背了一堆用不上的概念。