先說一個我自己的感受大部分代碼腐化不是從業(yè)務邏輯開始的而是從“依賴了一個不該依賴的外部接口”開始的。很多時候我們寫功能特別順手直接調(diào)第三方SDK、老系統(tǒng)接口、或者另一個團隊的服務參數(shù)照著文檔填異常隨手拋字段直接用跑起來沒問題就算完事。直到某一天外部服務升級協(xié)議、換了返回結(jié)構、或者干脆下線舊接口你才發(fā)現(xiàn)自己系統(tǒng)里有幾十處調(diào)用在跟著改而且每一處都改得提心吊膽。適配器模式要解決的核心問題就是把這種“變化”隔離在系統(tǒng)邊界之外。它的思想很簡單讓業(yè)務代碼只依賴自己定義的穩(wěn)定接口而把所有外部的東西塞進一個適配層里由適配層去消化變化、翻譯差異、轉(zhuǎn)換模型。這篇文章我不會從類圖開始講因為講類圖的資料已經(jīng)夠多了。我想結(jié)合這些年做接口對接、老系統(tǒng)改造的真實經(jīng)驗把適配器到底隔離什么、為什么值得用、怎么一步步落地以及最容易把自己繞進去的幾個坑全部攤開說清楚。適合正在接第三方服務的開發(fā)適合在維護老系統(tǒng)的團隊也適合做設計決策時擔心“改一處炸一片”的架構師參考。1. 先弄明白“變化”是什么適配器才不是空談1.1 適配器真正在處理的三種變化很多講適配器模式的文章一上來就畫三個類名然后說“這就是適配器”但看完你會發(fā)現(xiàn)還是不知道在項目里哪里該用。問題就出在沒有先回答一個更根本的問題適配器到底在隔離什么“變化”根據(jù)我自己的項目經(jīng)驗它要處理的“變化”主要有三類。第一類是外部依賴自身的演進。第三方服務升級版本、調(diào)整參數(shù)名、增加鑒權方式、甚至直接下線某個老接口這些都不是你能控制的。你唯一能控制的是自己系統(tǒng)內(nèi)部的改動范圍。如果沒有適配層這種變化就會順著調(diào)用鏈一路傳染到所有業(yè)務模塊里。第二類是同類外部服務之間的差異。比如你接了兩家云存儲、兩個短信服務商或者多個支付渠道。它們做的是同一類事情但API風格、數(shù)據(jù)結(jié)構、鑒權方式、錯誤碼體系統(tǒng)統(tǒng)不一樣。適配器在這里的角色像是把“各國插座標準”統(tǒng)一成“我們內(nèi)部的插頭規(guī)格”讓上層代碼看到的永遠是同一個樣子。第三類是外部模型和內(nèi)部模型之間的差異。外部SDK可能用“分”做金額單位業(yè)務系統(tǒng)用“元”外部狀態(tài)碼是“0成功、1失敗、2處理中”業(yè)務系統(tǒng)理解的是“SUCCESS、FAILED、PROCESSING”外部訂單號帶有廠商前綴而內(nèi)部訂單號有自己的長度限制。這些差異看著小但如果散落在每個調(diào)用點每次轉(zhuǎn)換都可能出錯。適配器模式之所以叫“適配器”就是因為它專門用來解決“接口形態(tài)不匹配”的問題。它不去改變外部系統(tǒng)的行為也不改變自己系統(tǒng)的業(yè)務規(guī)則它在中間做翻譯兩邊都保持原樣。這和一個電源轉(zhuǎn)換頭的邏輯完全一樣——墻上的插座不會變你的設備插頭也不會變中間加一個轉(zhuǎn)接頭就都能用了。1.2 適配器模式的結(jié)構一句話說清楚適配器的標準結(jié)構里有四個角色但真正理解它只需要抓住一句話調(diào)用方依賴自己的端口接口適配器負責把外部接口嫁接到這個端口上。Target也就是端口Port是調(diào)用方真正依賴的抽象接口由你系統(tǒng)內(nèi)部定義語義也必須由你來定。比如PaymentPort。Adaptee被適配的現(xiàn)有對象可能是第三方SDK、遺留系統(tǒng)的遠程接口、或者另一個服務暴露的API。Adapter適配器本體實現(xiàn)Target接口內(nèi)部包裝Adaptee把外部調(diào)用轉(zhuǎn)成內(nèi)部語義。Client使用Target接口的業(yè)務代碼它完全不感知Adaptee的存在。這里的關鍵是端口接口的定義權必須在自己手里。如果你直接把外部SDK暴露出來的接口當成本系統(tǒng)接口讓所有業(yè)務代碼去編譯依賴它那這個SDK的任何一個變化都會變成你的系統(tǒng)變化。反過來如果你先定義了業(yè)務真正需要的接口再讓適配器去適配外面的世界再怎么變業(yè)務代碼的編譯產(chǎn)物都可以一動不動。1.3 適配器和防腐層的關系聊適配器的時候經(jīng)常會冒出來另一個詞防腐層。很多人把它們當成一回事實際上粒度不一樣。防腐層是領域驅(qū)動設計里常用的一個邊界概念它保護核心領域不受外部上下文污染除了接口轉(zhuǎn)換還會包含協(xié)議翻譯、數(shù)據(jù)校驗、模型映射、外部服務的開關與容錯。適配器是防腐層最常見的落地手段之一但防腐層更強調(diào)“邊界”適配器更強調(diào)“轉(zhuǎn)換”。你完全可以在一個防腐層里面放多個適配器分別對應不同的外部服務。也可以只做一個適配器哪怕它只承擔了一次協(xié)議轉(zhuǎn)換。它們不是替代關系而是層次關系。把這個概念理清楚之后你再看網(wǎng)上的爭議文章就會發(fā)現(xiàn)絕大多數(shù)爭論都是因為把這兩個概念混在一起了。我在做邊界設計時一般會先識別“哪里是防腐邊界”再決定“邊界上需要幾個適配器”順序不要反。2. 為什么說隔離變化比消滅變化更務實2.1 你能控制的范圍往往比想象中小很多剛工作沒幾年的同學都有一個理想化的習慣看到外部接口不順眼就想著讓外部團隊改改到符合自己的使用習慣。比如字段命名不規(guī)范、狀態(tài)碼含義模糊、沒有超時控制、文檔更新滯后。這些問題確實存在但現(xiàn)實是外部系統(tǒng)是別的團隊在維護它的演進節(jié)奏不會為你的適配感負責。老系統(tǒng)改造的場景里更明顯。遺留系統(tǒng)的接口不能動因為還有大量老業(yè)務依賴數(shù)據(jù)表結(jié)構不能改因為幾百個查詢都在用。你能做的只有在新系統(tǒng)和老系統(tǒng)之間加一層翻譯。所以我在多次實踐中把設計心態(tài)理順了隔離變化不是消滅變化消滅變化是幻想隔離變化才是工程。外部世界你改不了你能控制的是把外部變化的影響控制在一個薄層里讓它不要在核心業(yè)務里到處流竄。這就是適配器最大的價值也是“隔離”二字的真正含義。2.2 隔離帶來的三個具體好處第一是可測試。業(yè)務代碼依賴的是自己定義的端口接口你完全可以在單元測試里用一個模擬實現(xiàn)替代真實的第三方調(diào)用。不需要起動外部服務不需要準備真實的測試賬號更不需要擔心測試環(huán)境網(wǎng)絡抖動。這一點在寫業(yè)務單測的時候非常舒服你會發(fā)現(xiàn)業(yè)務模塊的測試基本不需要再Mock外部SDK了端口后面掛的本來就是假實現(xiàn)。第二是可替換。哪天你發(fā)現(xiàn)當前的外部服務費用太高、穩(wěn)定性太差、或者不再維護要切換到另一個同類服務理論上只需要寫一個新的適配器換上去業(yè)務代碼一行都不用動。我在現(xiàn)實中經(jīng)歷過一次支付渠道切換整個切換花了三天其中兩天半在寫新適配器業(yè)務側(cè)真正改動的代碼收斂在兩個配置項和一個開關上。如果沒有適配層這個時間至少要放大五倍。第三是可演進。因為端口接口的語義是業(yè)務側(cè)的你可以讓接口向著自己系統(tǒng)的業(yè)務語言進化。比如你可以在端口里定義一個queryTransferStatus方法而外部SDK可能叫getTrade(queryOrderRequest)。名字不重要重要的是業(yè)務代碼讀起來像業(yè)務而不是像接口文檔。系統(tǒng)的長期維護性很大程度就體現(xiàn)在這種“業(yè)務代碼能否自解釋”上。2.3 適配器不是銀彈什么時候不該上隔離變化很香但不是所有場景都要上適配器。如果外部接口非常穩(wěn)定、改動頻率極低、系統(tǒng)生命周期又短那硬套一層適配器反而是過度設計的開始。我曾經(jīng)接手過一個內(nèi)部工具項目里面調(diào)了一個登錄服務接口三年沒變過但前任硬是給這個登錄服務加了三層接口抽象、適配器、封裝Facade每個方法都是三層轉(zhuǎn)發(fā)。結(jié)果代碼可讀性極差調(diào)試一個問題要跨三層斷點。判斷標準我用一個公式變化概率乘以影響范圍。只有在你判斷這個外部依賴有較大概率會變或者影響范圍很大時適配器才物有所值。給“永遠不會變的只讀服務”加適配器跟“為了明天可能下雨就買一輛水陸兩用車”差不多。別為虛構的明天設計這是隔離變化設計里最需要克制的一點。3. 核心實戰(zhàn)場景第三方支付接口的適配層設計3.1 場景還原為什么不能直接調(diào)SDK我拿一個最常見的場景舉例給業(yè)務系統(tǒng)接入在線支付。一開始你對接了某個支付服務商它的SDK提供了下單、退款、查詢等方法。業(yè)務團隊為了趕工期直接在訂單模塊、退款模塊里四處調(diào)用這個SDK。一開始沒什么問題但很快你發(fā)現(xiàn)幾個隱患SDK的請求對象和響應對象到處出現(xiàn)在業(yè)務代碼里代碼被第三方實現(xiàn)深度“綁架”異常處理不一致有的地方直接拋ThirdApiException有的地方捕獲后翻譯成自己的錯誤碼風格混亂退款和下單的返回狀態(tài)語義不統(tǒng)一有的接口返回“成功”是指“提交成功”有的是“處理成功”。一旦業(yè)務代碼散落著外部SDK的類型換服務商或者升級SDK就會變成一場災難。你必須在每個調(diào)用點去核對第三方返回值、異常類型、字段映射稍微漏一個地方生產(chǎn)環(huán)境就會冒出一堆詭異問題。適配器模式在這里不是可選項而是基本盤。3.2 端口先行先定義你的系統(tǒng)需要的接口正確做法是先忘掉那個支付SDK回到業(yè)務本身。問一個問題訂單系統(tǒng)、退款系統(tǒng)、賬務系統(tǒng)它們真正需要支付能力做什么答案大多是三件事發(fā)起支付、查詢結(jié)果、發(fā)起退款。于是你定義一個干凈的業(yè)務端口public interface PaymentPort { PaymentResult createPayment(PaymentCommand command); PaymentResult queryPayment(String bizOrderNo); PaymentResult refund(PaymentCommand command); }這個接口有幾個特點值得注意。第一參數(shù)是我方業(yè)務模型比如PaymentCommand里有bizOrderNo內(nèi)部訂單號、amountBigDecimal元、paySubject商品描述而不是第三方SDK里的供應商編號、分單位金額、渠道編號等概念。第二返回值統(tǒng)一成PaymentResult業(yè)務層只用code、message、外部交易號即可不需要理會第三方的各種回調(diào)數(shù)據(jù)結(jié)構。第三方法簽名以業(yè)務語義命名閱讀代碼的人不會產(chǎn)生理解偏差。我把這樣的接口稱為“端口”因為它是業(yè)務領域和外部世界之間一條定義明確的連接線。端口里面聲明什么、不聲明什么直接決定了后面變化侵入系統(tǒng)的面積。3.3 適配器實現(xiàn)的關鍵代碼有了端口接下來寫支付服務商的適配器。適配器的職責就是把外部SDK的調(diào)用方式“翻譯”成端口定義的方式。我給出一個典型骨架語言用Java描述其他語言的思路完全一致public class PayProviderXAdapter implements PaymentPort { private final PayProviderXClient client; public PayProviderXAdapter(PayProviderXClient client) { this.client client; } Override public PaymentResult createPayment(PaymentCommand command) { try { BuildPayRequest req new BuildPayRequest(); // 單位轉(zhuǎn)換元 - 分 req.setAmount(toCents(command.getAmount())); req.setBizOrderNo(command.getBizOrderNo()); req.setSubject(command.getPaySubject()); PayResponse resp client.pay(req); return PaymentResult.of(resp.isSuccess(), codeOf(resp.getStatus()), resp.getTradeNo()); } catch (PayProviderXTimeoutException e) { // 外部超時理論上訂單狀態(tài)未知需要查詢確認不能直接算失敗 throw new PaymentPortUncertainException(provider timeout, e); } catch (PayProviderXRejectedException e) { // 業(yè)務拒絕余額不足、風控攔截等 throw new PaymentPortBusinessException(e.getMessage(), e); } } Override public PaymentResult refund(PaymentCommand command) { // 同樣的翻譯邏輯 } }你別小看這個代碼片段里面每一個細節(jié)都是在實戰(zhàn)中打磨出來的。金額單位必須在這里轉(zhuǎn)一次避免業(yè)務層到處做“元轉(zhuǎn)分”。外部超時不能簡單當作失敗因為第三方可能已經(jīng)扣款成功了所以拋出一個“不確定”異常讓上層走查詢補償流程。第三方業(yè)務拒絕要翻譯成業(yè)務拒絕讓上層能拿到可讀的錯誤語義。這些決策看起來很瑣碎但它們決定了整個系統(tǒng)的邊界質(zhì)量。3.4 模擬適配器不只是測試玩具按同樣的端口再寫一個模擬適配器public class MockPaymentPort implements PaymentPort { Override public PaymentResult createPayment(PaymentCommand command) { if (1.equals(command.getBizOrderNo())) { // 模擬一個被風控拒絕的場景 throw new PaymentPortBusinessException(mock risk reject); } return PaymentResult.of(true, TRADE_SUCCESS, MOCK command.getBizOrderNo()); } Override public PaymentResult refund(PaymentCommand command) { return PaymentResult.of(true, SUCCESS, MOCK_REFUND command.getBizOrderNo()); } }很多人把模擬適配器只當成單元測試的玩具其實它的價值遠不止測試。在前后端并行開發(fā)、聯(lián)調(diào)環(huán)境不穩(wěn)定的時候業(yè)務模塊可以直接掛上模擬適配器先跑通流程等真實服務準備好了再切換過去。想模擬第三方超時、風控拒絕、重復回調(diào)都能在模擬實現(xiàn)里輕松構造。我自己在項目里還會給模擬適配器加上延遲參數(shù)用來模擬真實網(wǎng)絡延遲讓前端體驗接近真實的交互耗時。需要注意的是模擬適配器不能偷偷留在生產(chǎn)環(huán)境里。它在開發(fā)環(huán)境是利器在生產(chǎn)環(huán)境就是事故導火索。我見過一個團隊測試完忘改配置導致線上支付流程走的是模擬通道雖然最終沒有真扣款但對用戶已經(jīng)造成了明顯業(yè)務影響。所以切換邏輯要干凈最好通過配置中心控制并且配置變更要帶上線審批和監(jiān)控告警。4. 完整實操過程從一個老系統(tǒng)開始做適配改造4.1 第一步梳理調(diào)用點找到變與不變的分界線做適配改造尤其是給老系統(tǒng)做改造不能上來就寫抽象接口得先盤點現(xiàn)狀。我通常會做三件事找出所有第三方調(diào)用點列出外部接口的參數(shù)和返回結(jié)構再標記哪些字段是業(yè)務真正關心的。在調(diào)用點梳理過程中你會發(fā)現(xiàn)一個規(guī)律同一個外部接口常常被多個模塊反復調(diào)用而且每個模塊對返回結(jié)果的使用方式還不一樣。有的模塊關心外部單號有的關心狀態(tài)碼有的關心金額有的只關心是否成功。這些使用者都是你定義端口的參考對象。變與不變的分界線怎么找我建議以“業(yè)務世界”為準。業(yè)務不關心第三方SDK怎么傳參它只關心“支付發(fā)起成功沒有”“退款到賬沒有”。所以端口接口應該表達業(yè)務狀態(tài)而不應該表達外部調(diào)用。簡單說如果你的端口方法簽名里出現(xiàn)了某個具體供應商的名稱、字段、錯誤碼那這個端口就沒有設計到位。4.2 第二步寫適配器骨架把轉(zhuǎn)換規(guī)則列成表格動手寫編碼之前先把轉(zhuǎn)換規(guī)則列出來。我習慣在項目文檔里維護三張表形式類似這樣業(yè)務字段端口側(cè)供應商字段SDK側(cè)轉(zhuǎn)換規(guī)則bizOrderNoout_trade_no直接映射amount元amount分乘以100取整paySubjectbody截斷到128字符供應商返回狀態(tài)業(yè)務狀態(tài)說明TRADE_SUCCESSSUCCESS明確成功TRADE_CLOSEDFAILED系統(tǒng)關閉WAIT_BUYER_PAYPROCESSING等待支付UNKNOWNUNCERTAIN需查詢確認異常類型業(yè)務異常后續(xù)處理建議超時異常UncertaintyException發(fā)起查詢或?qū)~業(yè)務拒絕BusinessException提示用戶簽名異常InfraException告警檢查配置限流錯誤RetryableException延遲重試或降級有了這三張表適配器的代碼寫起來就是純粹的“翻譯”不太容易漏邏輯。更重要的是這三張表沉淀下來之后下一次換供應商新適配器的開發(fā)會快很多因為業(yè)務側(cè)要什么已經(jīng)是確定的只需填表映射。4.3 第三步異常翻譯與監(jiān)控埋點適配器里最容易忽略的不是主流程而是異常翻譯。很多代碼在外層兜底捕獲了一個Exception卻不知道怎么處理。真實的情況是外部異常至少分四類技術異常超時、連接失敗、簽名錯誤、業(yè)務異常余額不足、風控拒絕、狀態(tài)不確定異常請求超時但可能已經(jīng)處理、編程異常參數(shù)非法、配置錯誤。這四類異常在上層看來處理策略完全不同不能在適配器里一鍋燴成RuntimeException。我處理的原則是端口接口只拋業(yè)務語義的異常。適配器要對每一種外部錯誤做翻譯把技術異常包裝成基礎設施異常把業(yè)務異常翻譯成業(yè)務錯誤把不確定異常單獨建模。這會讓上層代碼的錯誤處理邏輯變得很清晰而不會出現(xiàn)上層到處 catch 第三方異常類的情況。監(jiān)控埋點在適配器里也比在業(yè)務層里做更合適。每次調(diào)用記錄耗時、成功/失敗、失敗原因這些指標天然和外部依賴綁定。我在適配器里加了簡單的計數(shù)器上線后能直觀看到每個供應商的可用率。一旦某個供應商出問題監(jiān)控圖上立刻能看出來而不是等到業(yè)務報障才發(fā)現(xiàn)。4.4 第四步雙實現(xiàn)切換與回歸測試老系統(tǒng)改造最怕一次性一刀切切過去就回不來。我的做法是構建雙實現(xiàn)并存機制保留舊的直連調(diào)用邏輯新適配器通過配置開關決定是否啟用。配置中心的開關打開后讓一小部分流量先走適配器觀察業(yè)務指標和日志確認沒問題再逐步切完。在回歸測試上我會重點驗證幾類場景正常成功鏈路、金額為0的邊界、超時后重查鏈路、第三方返回業(yè)務拒絕、重復退款、回調(diào)亂序。這些測試用例盡量用模擬適配器來測業(yè)務層用真實供應商小額度來驗證適配器本身。兩者結(jié)合既能保障業(yè)務邏輯穩(wěn)定又能驗證真實接入正確性。這個改造過程看起來環(huán)節(jié)多但每一步都不難難的是沉住氣把調(diào)用點梳理清楚。很多團隊改造失敗不是適配器寫得有問題而是根本沒盤點清楚哪些地方在用外部接口結(jié)果切配置之后漏了幾個調(diào)用點導致線上出現(xiàn)問題。5. 踩坑實錄適配器寫歪了以后的樣子5.1 坑一適配器里堆滿業(yè)務規(guī)則適配器最典型的腐爛方式就是寫著寫著把業(yè)務規(guī)則也塞進去了。比如外部狀態(tài)為SUCCESS時適配器里順便做了一個“如果訂單金額大于1000元就走人工審核”的判斷或者適配器里直接操作了數(shù)據(jù)庫修改訂單狀態(tài)。這些規(guī)則一旦埋進適配器就會變得難以測試、難以復用還會讓適配器層變成一個新的“大泥球”。為什么會出現(xiàn)這個坑因為寫代碼的時候覺得這個判斷順手放這里最方便不用再去改別的類。代價是邊界被悄悄模糊了適配器不再是純粹的翻譯層而是承擔了業(yè)務編排職責。我的糾偏經(jīng)驗是給適配器設定一個紀律它只能做四件事——參數(shù)映射、調(diào)用外部服務、響應映射、異常翻譯。任何超出這四件事的邏輯一律放到適配器之外的業(yè)務服務里。評判標準很簡單如果適配器里出現(xiàn)“if 金額 xxx”這類業(yè)務分支就該重構。5.2 坑二把外部異常直接拋給上層還有一個非常常見的坑就是適配器捕獲異常之后不做翻譯直接把第三方異常原樣拋出去。外面看日志還好但業(yè)務模塊的 catch 就遭殃了。業(yè)務層為了處理第三方異常你得引用對方的異常類型為了拿到錯誤詳情你得解析第三方錯誤對象。這等于把外部依賴的細節(jié)從適配器泄漏給了全部調(diào)用方。我在一個遺留系統(tǒng)里看過這樣的代碼業(yè)務層同時 catch 了兩家供應商的異常類型還在 switch 里分別處理錯誤碼。每加一個供應商業(yè)務層就要加一組 case這就是沒有做異常翻譯的后果。適配器的異常出口應該是自解釋的上層看到一個PaymentPortBusinessException就知道這是“業(yè)務可以處理的失敗”看到技術異常就知道得走降級邏輯。5.3 坑三適配器實例狀態(tài)混亂造成線程安全問題適配器在大多數(shù)情況下應該是無狀態(tài)的但有些人習慣在適配器里保存某個本次請求的上下文比如請求ID、用戶ID。一旦這個適配器被多個線程共享這些字段就會被互相覆蓋輕則日志串號重則把A用戶的請求參數(shù)拼到B用戶的請求里。我見過一個真實事故適配器里一個成員變量保存了訂單號然后業(yè)務用異步線程池去調(diào)用支付多筆訂單并發(fā)時訂單號互相污染導致扣錯了款。排查到根因后把成員變量全部改成方法參數(shù)傳遞問題才徹底消失。所以要牢記適配器實例本身是單例擴用的臨時數(shù)據(jù)必須走方法參數(shù)不能存成員變量。如果需要保存請求上下文要使用獨立的上下文容器而不是直接定義在適配器里。5.4 坑四為適配而適配純粹的過度設計和前面幾個坑相反還有一種失敗是搞了一堆不必要的抽象。比如系統(tǒng)里只有一個外部服務這個服務也很穩(wěn)定但設計者還是畫了三層接口配了四個適配器類然后到處聲明“為未來擴展做好準備”。結(jié)果是任何人讀代碼都要在多層間接里跳來跳去還沒等到那個“未來”團隊已經(jīng)被維護成本拖垮了。判斷是不是過度設計我會看一個信號適配器的文件名里是不是全部帶同一個動詞比如XxxAdapter、YyyAdapter、ZzzAdapter但其中至少有兩個方法體是完全一樣的轉(zhuǎn)發(fā)。如果出現(xiàn)這個信號說明抽象粒度有問題不如先合并或者刪掉一層。5.5 排查適配層問題的檢查清單經(jīng)驗沉淀后我給團隊整理過一份適配層自查清單每次代碼評審都拿出來對著過一遍外部SDK類型是否出現(xiàn)在端口接口和業(yè)務代碼里出現(xiàn)即視為泄漏。適配器里是否存在業(yè)務分支、數(shù)據(jù)庫操作、狀態(tài)判斷存在即視為越權。外部異常類是否被上層直接引用參考所有 catch 的異常類型。單位轉(zhuǎn)換、字段映射是否只出現(xiàn)一次重復出現(xiàn)就是隱患。適配器是否可單測可測試的標準是不依賴真實外部服務。換一個供應商業(yè)務側(cè)需要改幾行理想答案是0行。這份清單雖然簡單但能擋住大部分適配層的低級問題。我在多次評審里發(fā)現(xiàn)真正被攔下來的代碼問題其實都是這些看起來基礎的規(guī)則被忽略了。6. 適配器與鄰接模式邊界劃分和配合6.1 策略模式和適配器一起用適配器負責把外部接口翻譯成內(nèi)部端口策略模式負責讓同一端口下多個實現(xiàn)可以靈活選擇。兩者經(jīng)常一起出現(xiàn)。比如你定義了SmsPort然后寫了ProviderAAdapter和ProviderBAdapter再按流量比例切換或按地區(qū)路由這就是策略調(diào)適配器。沒有適配器策略模式的選擇對象會變成各種外部SDK接口語義差異會放大沒有策略模式你每次想切供應商就得改適配器的實例化代碼。它們的關注點不同適配器解決的是“長什么樣”的問題策略解決的是“選哪個”的問題。在代碼結(jié)構上就是兩層策略層持有端口引用適配器實現(xiàn)端口。這個組合幾乎覆蓋了所有“多供應商接入”的需求。6.2 門面與適配器簡化不等于轉(zhuǎn)譯門面和適配器經(jīng)常被搞混因為它們都可以包裝某個復雜的子系統(tǒng)。區(qū)分方式很簡單適配器是為了讓“本來不兼容的接口變得兼容”門面是為了讓“一堆復雜的交互變得簡單”。比如你有一個短信服務、一個郵件服務、一個站內(nèi)信服務然后做一個通知門面上層調(diào)一個send()就完成多渠道通知這是門面。而針對其中某一家短息服務商做協(xié)議翻譯那是適配器。門面可能沒有外部兼容問題它只是簡化。適配器則有明確的兩側(cè)協(xié)議不兼容才需要翻譯。在系統(tǒng)設計時常見的情況是門面后面再掛適配器門面提供統(tǒng)一入口適配器負責對接不同供應商。這兩者的協(xié)作會讓邊界更清晰但如果混用代碼讀起來就會很迷糊。6.3 代理與適配器控制訪問與協(xié)議轉(zhuǎn)換代理模式也和適配器很像都持有目標對象都包了一層。但代理的核心目的是控制訪問比如延遲加載、訪問控制、日志記錄它不改變接口形態(tài)適配器的核心目的是轉(zhuǎn)換接口它必須改變接口形態(tài)。所以在實現(xiàn)上有一個簡單判斷法客戶端拿到的對象接口和代理持有的目標對象接口是否一致一致是代理不一致是適配器。實際項目中我也會把兩者疊起來先用適配器把外部接口翻譯成內(nèi)部端口然后在適配器外包一層監(jiān)控代理統(tǒng)計調(diào)用指標。這樣適配器仍然專注于翻譯代理專注橫切關注點各司其職。6.4 模板方法固定適配流程策略處理差異性如果適配多個供應商時發(fā)現(xiàn)它們的調(diào)用流程高度相似只是細節(jié)不同可以用模板方法模式把流程固定下來把差異部分交給子類實現(xiàn)。比如不管是哪個支付服務商調(diào)用流程都是“組裝請求、發(fā)請求、解析響應、處理異?！敝皇墙M裝方式不同、解析方式不同。做成一個抽象的BasePaymentAdapter提供process()模板子類只需實現(xiàn)buildRequest()和parseResponse()能大幅減少重復代碼。但這個優(yōu)化有兩個前提流程確實高度一致并且你有多個適配器。如果只有兩個適配器模板方法也可以但一定要警惕“為了復用而硬抽出公共父類”那會讓父子類關系變得很別扭。做過的系統(tǒng)越多我越發(fā)現(xiàn)一個規(guī)律真正讓項目長期穩(wěn)定的往往不是復雜的業(yè)務模型而是這些看起來不起眼的隔離層。適配器就是典型代表它的實現(xiàn)成本不高收益卻非常直接——外部世界再亂業(yè)務代碼依然可以保持自己的語言和節(jié)奏。我的建議是在項目里第一次出現(xiàn)“后面可能要換供應商”“這個接口是別的團隊維護的”這種話時就順手把適配器建起來。就算最終沒換成你也會得到一個更干凈的測試接口和一個更容易解釋的系統(tǒng)邊界。設計這東西很多時候圖的就是關鍵時刻不用抓瞎。