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