結(jié)構(gòu)型模式的最后一個,是橋接模式(Bridge)。它可能是七個結(jié)構(gòu)型里最抽象、也最容易被講得云里霧里的一個,但只要抓住它要解決的那個具體問題,就會豁然開朗。這個問題是:當一個東西同時在兩個(或多個)獨立的維度上變化時,如果用繼承去表達,類的數(shù)量會維度相乘式爆炸。我們在裝飾器那篇見過一次類爆炸(2? 組合),但那是同一維度的多個可選增強的疊加。橋接面對的是另一種類爆炸,更常見也更隱蔽——兩個正交維度的交叉。舉個我們訂單場景里的例子:訂單有不同類型(普通訂單、團購訂單、預(yù)售訂單),發(fā)通知又有不同渠道(短信、App 推送、郵件)。這是兩個完全獨立的維度:訂單類型的增減,和通知渠道的增減,毫不相干。可如果你用繼承硬來,就會寫出普通訂單短信通知、普通訂單App通知、團購訂單郵件通知……3 種類型 × 3 種渠道 9 個類,再加一種類型或渠道,就是 12 個、16 個,呈乘法增長。橋接模式的核心思想,就是把這兩個糾纏在一起的維度拆開,讓它們各自獨立地變化,再用一座橋把它們連起來。GoF 給它的正式定義是一句很經(jīng)典但初看費解的話:“將抽象部分與它的實現(xiàn)部分分離,使它們都可以獨立地變化?！?這一篇我們就把這句話徹底翻譯成人話。這篇文章按這條線索展開:先復(fù)現(xiàn)兩個維度用繼承導(dǎo)致的乘法類爆炸;再引出橋接如何把維度拆開、用組合搭一座橋;然后講清那句抽象與實現(xiàn)分離到底在說什么(這是全篇最關(guān)鍵、也最容易誤解的地方);接著看它的現(xiàn)實身影;最后辨析它與相近模式,給出適用邊界,并為結(jié)構(gòu)型模式畫上句號。貫穿例是訂單類型 × 通知渠道。目錄兩個維度用繼承:乘法式類爆炸橋接模式:把維度拆開,搭一座橋抽象與實現(xiàn)分離到底在說什么現(xiàn)實身影:JDBC 與日志框架橋接 vs 相近模式,以及什么時候用結(jié)構(gòu)型模式,到此收官一、兩個維度用繼承:乘法式類爆炸先把問題擺清楚。我們要做給訂單發(fā)通知這件事,它牽涉兩個維度:維度 A:訂單類型—— 普通訂單、團購訂單、預(yù)售訂單(不同類型通知的文案、邏輯不同);維度 B:通知渠道—— 短信、App 推送、郵件(不同渠道的發(fā)送方式不同)。如果用繼承來表達某類訂單通過某渠道發(fā)通知,你會不自覺地寫成這樣:abstractclassOrderNotify{abstractvoidnotifyUser();}// 為類型 × 渠道的每一種組合,都建一個類classNormalOrderSmsNotifyextendsOrderNotify{...}// 普通訂單 短信classNormalOrderAppNotifyextendsOrderNotify{...}// 普通訂單 AppclassNormalOrderEmailNotifyextendsOrderNotify{...}// 普通訂單 郵件classGroupOrderSmsNotifyextendsOrderNotify{...}// 團購訂單 短信classGroupOrderAppNotifyextendsOrderNotify{...}// 團購訂單 App// ... 3 類型 × 3 渠道 9 個類災(zāi)難在于乘法增長:現(xiàn)在是 3×39 個類。產(chǎn)品說再加一個預(yù)售的訂單類型,你要加 3 個類(配齊三個渠道);運營說接入一個企業(yè)微信渠道,你要加 3 個類(配齊三種訂單)。每增加一個維度上的一項,類的數(shù)量就按另一個維度的規(guī)模成倍增加。而且這些類里全是重復(fù)——NormalOrderSmsNotify和GroupOrderSmsNotify里,發(fā)短信的代碼幾乎一樣,只是訂單文案不同。問題的根源是:繼承只有一條軸,卻被迫同時表達兩個維度。你把訂單類型和通知渠道這兩件本來毫不相干的事,硬塞進了同一條繼承鏈,于是它們被死死綁在一起,任何一個變,都牽動另一個。正確的直覺應(yīng)該是:這倆維度本來就該分開。訂單類型該有自己的一套類,通知渠道該有自己的一套類,然后在運行時把某個類型和某個渠道自由組合起來——3 個類型類 3 個渠道類 6 個類,就能覆蓋 9 種組合;以后加一個類型是 1,加一個渠道也是 1,變回了加法。怎么做到?用組合,搭一座橋。二、橋接模式:把維度拆開,搭一座橋橋接的做法:把兩個維度拆成兩套獨立的繼承體系,然后讓其中一個體系(抽象)持有另一個體系(實現(xiàn))的引用——這個持有的組合關(guān)系,就是那座橋。先把通知渠道這個維度獨立出來,做成一套體系(橋接里管它叫實現(xiàn)部分):// 維度 B:通知渠道 —— 獨立的一套體系publicinterfaceNotifyChannel{voidsend(Stringmessage);}classSmsChannelimplementsNotifyChannel{publicvoidsend(Stringm){/* 發(fā)短信 */}}classAppChannelimplementsNotifyChannel{publicvoidsend(Stringm){/* App 推送 */}}classEmailChannelimplementsNotifyChannel{publicvoidsend(Stringm){/* 發(fā)郵件 */}}再把訂單類型這個維度也獨立出來(橋接里管它叫抽象部分),關(guān)鍵是——它持有一個NotifyChannel引用,這就是橋:// 維度 A:訂單類型 —— 另一套體系,持有渠道引用(這就是橋)publicabstractclassOrderNotify{protectedfinalNotifyChannelchannel;// ← 橋:持有另一個維度publicOrderNotify(NotifyChannelchannel){this.channelchannel;}publicabstractvoidnotifyUser();}classNormalOrderNotifyextendsOrderNotify{publicNormalOrderNotify(NotifyChannelchannel){super(channel);}publicvoidnotifyUser(){channel.send(您的訂單已創(chuàng)建);// 委托給渠道去發(fā),自己只管文案}}classGroupOrderNotifyextendsOrderNotify{publicGroupOrderNotify(NotifyChannelchannel){super(channel);}publicvoidnotifyUser(){channel.send(拼團成功,訂單已生成);// 團購的文案不同,但發(fā)送委托給渠道}}現(xiàn)在,某類訂單 某渠道的組合,是在運行時自由拼出來的:// 普通訂單 短信OrderNotifyn1newNormalOrderNotify(newSmsChannel());n1.notifyUser();// 團購訂單 郵件 —— 隨意組合,不用新建類OrderNotifyn2newGroupOrderNotify(newEmailChannel());n2.notifyUser();對比第一節(jié),升級點非常清晰:類的數(shù)量從 3×39 個,降到了 336 個;從乘法變回了加法。加一個訂單類型?加一個OrderNotify子類(1)。加一個通知渠道?加一個NotifyChannel實現(xiàn)(1)。兩個維度各自獨立地變化,誰也不牽連誰——這正是 GoF 定義里都可以獨立地變化的含義。用一張圖看這座橋最直觀:圖里最該記住的,就是中間那條連接兩套體系的橋(OrderNotify持有NotifyChannel)。左右兩欄可以各自向下無限擴展,而它們的組合數(shù)是左 × 右,類的數(shù)量卻只是左 右。橋接的全部威力,就濃縮在這座用組合搭起來的橋上——它又一次是組合優(yōu)于繼承的勝利。三、抽象與實現(xiàn)分離到底在說什么現(xiàn)在來啃 GoF 那句定義:“將抽象部分與它的實現(xiàn)部分分離?！?這句話之所以讓無數(shù)人困惑,是因為這里的抽象和實現(xiàn),不是我們平時說的抽象類/接口和實現(xiàn)類的意思。必須把它翻譯清楚,否則你會一直誤解橋接。在橋接的語境里:“抽象”(Abstraction)指的是主體維度、高層的那套邏輯—— 在我們的例子里就是OrderNotify(訂單類型)。它是面向用戶、定義要做什么的那一側(cè)?！皩崿F(xiàn)”(Implementor)指的是被主體維度調(diào)用的、底層的那套能力—— 就是NotifyChannel(通知渠道)。它提供具體怎么做的基礎(chǔ)操作,供上層調(diào)用。所以抽象與實現(xiàn)分離,翻譯成人話就是:把高層邏輯維度和底層能力維度拆成兩套獨立的體系,讓高層通過組合去調(diào)用底層,而不是用繼承把兩者焊死。OrderNotify(高層)通過持有的channel(橋)去調(diào)用NotifyChannel(底層)的能力,兩者解耦,各自能獨立擴展和替換。這里有個關(guān)鍵點,也是橋接和策略模式(下一篇)容易混的地方:橋接強調(diào)的是兩側(cè)都會獨立演化的、穩(wěn)定的維度劃分——它是一種架構(gòu)層面的結(jié)構(gòu)設(shè)計,你在設(shè)計之初就預(yù)見到這里有兩個正交維度會各自增長,于是提前用橋把它們分開。它不是臨時替換一個算法,而是讓兩個類體系長期地、各自地生長。理解了抽象主體維度、實現(xiàn)被調(diào)用的能力維度,橋接就不再神秘了——它就是把’本該分開的兩個維度’用組合連起來,如此而已。四、現(xiàn)實身影:JDBC 與日志框架橋接最經(jīng)典的工業(yè)級案例,是JDBC。想想 JDBC 的結(jié)構(gòu):抽象側(cè):java.sql包里的Connection、Statement、DriverManager這套 API,是面向應(yīng)用開發(fā)者的、穩(wěn)定的高層抽象——你寫的代碼只調(diào)這套接口;實現(xiàn)側(cè):各家數(shù)據(jù)庫廠商提供的JDBC 驅(qū)動(MySQL 的、Oracle 的、PostgreSQL 的),是底層實現(xiàn)——它們各自實現(xiàn)了 JDBC 定義的接口。你的應(yīng)用代碼(抽象側(cè))通過DriverManager持有一個具體的Driver(實現(xiàn)側(cè)),這就是那座橋。于是兩側(cè)獨立變化:JDK 升級 JDBC API(抽象側(cè)演進)不影響驅(qū)動;數(shù)據(jù)庫廠商更新驅(qū)動(實現(xiàn)側(cè)演進)不影響你的應(yīng)用代碼;你想從 MySQL 換成 Oracle,只需換個驅(qū)動(換實現(xiàn)),應(yīng)用代碼一行不改。這正是橋接抽象與實現(xiàn)各自獨立變化的完美體現(xiàn),也是為什么 JDBC 能讓一套代碼適配幾十種數(shù)據(jù)庫。另一個例子是日志框架的門面 實現(xiàn):SLF4J(抽象側(cè),統(tǒng)一 API) Logback/Log4j2(實現(xiàn)側(cè),具體日志實現(xiàn))。你的代碼面向 SLF4J,底層實現(xiàn)可隨意替換。有意思的是,SLF4J 我們在外觀那篇也提過。這說明一個真實的框架,往往同時用到多個模式:SLF4J 對使用者是外觀(簡化日志的使用),對API 與實現(xiàn)的解耦則體現(xiàn)了橋接的思想。模式不是互斥的標簽,而是從不同角度描述同一個設(shè)計的多個側(cè)面——不必糾結(jié)它到底是哪個模式,理解它解決了什么問題更重要。五、橋接 vs 相近模式,以及什么時候用橋接容易和幾個模式混,辨析一下:橋接 vs 策略(下一篇):兩者代碼結(jié)構(gòu)很像(都是持有一個接口引用、委托調(diào)用)。區(qū)別在意圖和粒度:策略是一個算法有多種可替換的實現(xiàn),關(guān)注的是運行時替換單一行為,通常只有一個變化維度(策略本身);橋接是兩個維度都會獨立、長期地擴展,關(guān)注的是架構(gòu)層面的維度分離,強調(diào)的是兩側(cè)各自成體系地生長。一句話:策略換的是一個算法,橋接分的是兩條演化軸。橋接 vs 適配器:適配器是事后補救——兩個已經(jīng)存在、接口不兼容的東西,加個轉(zhuǎn)接頭讓它們能協(xié)作;橋接是事前設(shè)計——在設(shè)計之初就主動把兩個維度分開,讓它們從一開始就能獨立生長。適配器解決已經(jīng)不兼容了怎么辦,橋接解決怎么設(shè)計才不會耦合。適合用橋接的信號:一個類存在兩個或多個獨立變化的維度(正交),且每個維度都可能擴展;你不希望這些維度之間用繼承產(chǎn)生乘法式的類爆炸;你想在運行時靈活組合不同維度的實現(xiàn)。不必用的信號:只有一個變化維度——那可能用策略、或者別的模式就夠了,橋接是為多維度準備的;兩個維度中有一個其實是穩(wěn)定的、幾乎不變的——那分離的收益不大,可能是過度設(shè)計。判斷的核心還是那句話:先確認真的存在兩個都會獨立增長的維度,橋接才有價值。很多時候你以為有兩個維度,其實一個維度是固定的,那就別為想象中的第二維度提前搭橋——這又是過度設(shè)計的陷阱。六、結(jié)構(gòu)型模式,到此收官第 13 篇結(jié)束,七個結(jié)構(gòu)型模式全部講完了。它們關(guān)心類和對象如何組合連接,我們用一張總表收尾,把整個家族刻進腦子:模式一句話核心意圖關(guān)鍵手法代理 Proxy給對象一個替身控制訪問同接口包裝 織入裝飾器 Decorator洋蔥層層包裹動態(tài)增強功能同接口 組合 遞歸適配器 Adapter接口轉(zhuǎn)接頭轉(zhuǎn)換接口轉(zhuǎn)換 委托組合 Composite單個和一組一樣統(tǒng)一處理樹形容器持有抽象組件外觀 Facade給子系統(tǒng)蓋門面簡化使用中間層收攏編排享元 Flyweight提取共享省內(nèi)存扛住海量對象內(nèi)外狀態(tài)分離 緩存池橋接 Bridge分離兩個維度讓維度獨立變化抽象持有實現(xiàn)(搭橋)回望這七個模式,一條主線貫穿始終:它們幾乎全都在用組合代替繼承。代理、裝飾、適配、橋接靠組合持有對象,組合靠組合搭樹,外觀靠組合收攏子系統(tǒng),享元靠組合(引用)共享。第一篇講的合成復(fù)用原則(組合優(yōu)于繼承),在整個結(jié)構(gòu)型家族里被反復(fù)驗證——當你想改變、擴展、連接對象的行為時,組合幾乎總比繼承更靈活。這也是結(jié)構(gòu)型模式給我們最深的一課。小結(jié)。橋接模式專治兩個獨立維度用繼承導(dǎo)致的乘法類爆炸。它把兩個維度拆成兩套獨立體系,讓抽象側(cè)(主體維度/高層邏輯)通過組合持有實現(xiàn)側(cè)(被調(diào)用的能力維度)的引用——這個組合關(guān)系就是橋,從而讓兩個維度各自獨立地變化,把類的數(shù)量從乘法變回加法。GoF 那句抽象與實現(xiàn)分離的真正含義,是把高層邏輯維度和底層能力維度解耦,JDBC 的 API 與驅(qū)動、SLF4J 與日志實現(xiàn)都是它的經(jīng)典身影。至此,結(jié)構(gòu)型七模式全部收官,而它們共同的底色,就是組合優(yōu)于繼承。從下一篇開始,我們進入設(shè)計模式里數(shù)量最多、也最精彩的一類——行為型模式,它們關(guān)心對象之間如何協(xié)作、如何分配職責(zé)。第一站是消滅if-else的利器:策略模式。