：接口轉(zhuǎn)換、對象適配器與第三方支付接入)
接手過老項目的人應(yīng)該都有這種體會系統(tǒng)里那些七零八落的接口沒有一個能和你新寫的代碼嚴(yán)絲合縫地對接上改老的怕出事改新的又覺得虧。這時候最穩(wěn)的辦法往往不是強行改某一方的代碼而是在中間加一層“轉(zhuǎn)接頭”讓雙方各干各的互不干擾。這件事放到設(shè)計模式里就是適配器模式Adapter Pattern。我最早接觸這個名字是在大學(xué)里看《Head First 設(shè)計模式》當(dāng)時覺得它不過是“把一個接口轉(zhuǎn)換成另一個接口”而已直到在真實項目里用了幾次才發(fā)現(xiàn)這個模式真正解決的問題不是接口長什么樣而是代碼和代碼之間的關(guān)系怎么處理。這篇文章不打算堆概念我會從為什么需要適配器開始講清楚兩種實現(xiàn)方式的取舍再拿一個接第三方支付的完整例子帶大家走一遍最后聊聊它在框架里的身影、配得上的坑以及和外觀模式、代理模式的邊界。內(nèi)容適合正在學(xué)設(shè)計模式的學(xué)生也適合寫業(yè)務(wù)代碼寫到快崩潰的工程師尤其適合那些想在老系統(tǒng)改造、多廠商對接場景里少走彎路的同學(xué)。1. 適配器模式到底在解決什么問題1.1 從電源插頭說起適配器這個詞其實從生活里來的。你從國外帶回來一個筆記本插頭是歐標(biāo)的兩個圓腳國內(nèi)排插是國標(biāo)的三扁腳或者兩扁腳直接懟進去基本不可能。這時候你不會把墻上的插座拆了重做更不會把筆記本的電源線剪了換頭而是去一趟超市買個轉(zhuǎn)換插頭十幾塊錢插上就能充。設(shè)計模式里的適配器干的就是這件事客戶Client面對的插座是標(biāo)準(zhǔn)接口外部系統(tǒng)Adaptee提供的插頭是另一種規(guī)格適配器Adapter就是中間那個轉(zhuǎn)換頭。它做的事情是讓原本因接口不匹配而無法協(xié)作的類可以一起工作并且在這個過程中雙方都不需要修改自己。放到設(shè)計模式的定義里適配器模式屬于結(jié)構(gòu)型模式結(jié)構(gòu)型模式關(guān)注的核心是“類和對象怎么組合”。組合得好系統(tǒng)就松耦合改A不炸B組合得爛牽一發(fā)而動全身。適配器模式就是為了解決“接口不匹配時的組合問題”而存在的。注意適配器不是萬能的。如果外部系統(tǒng)的行為邏輯和你期望的完全不同光靠接口轉(zhuǎn)換解決不了根本矛盾后面我會講到什么時候不該用適配器。1.2 需求場景與設(shè)計目標(biāo)用代碼場景來描述可能更直接。假設(shè)你現(xiàn)在寫了一個訂單服務(wù)內(nèi)部調(diào)用一個PaymentService接口public interface PaymentService { void pay(String orderId, double amount); }你的業(yè)務(wù)代碼到處都在依賴這個接口方法調(diào)用、參數(shù)類型、返回值全是按這個接口來設(shè)計的。結(jié)果后端突然告訴你公司的支付通道要換新通道SDK提供的接口長這樣public class NewPaySDK { public boolean charge(String bizOrderNo, BigDecimal money, String currency) { // 真實支付邏輯 return true; } }注意這里的問題不只是方法名不一樣還牽扯到了參數(shù)類型String對Long、double對BigDecimal、返回值語義void對boolean、甚至業(yè)務(wù)概念orderId對bizOrderNo。如果你選擇直接改PaymentService和所有調(diào)用方那訂單模塊、支付回調(diào)、對賬邏輯全部要跟著動改完還得全量回歸代價大到離譜。這時候適配器模式的思路就出來了保持PaymentService接口不動寫一個適配器類實現(xiàn)PaymentService內(nèi)部包住NewPaySDK在pay()方法里完成參數(shù)轉(zhuǎn)換和調(diào)用。對外你依然在用原來的接口對內(nèi)你已經(jīng)無縫切到了新SDK。整個過程調(diào)用方一行代碼都不用改。這個例子其實引出了適配器模式最重要的設(shè)計目標(biāo)把“變化的實現(xiàn)”和“穩(wěn)定的接口”隔離開。適配器模式允許你在兩邊都穩(wěn)定的前提下引入變化穩(wěn)定性來自接口不變變化性來自適配器可替換。這是它和很多模式最大的不同——它不是為了設(shè)計出新的交互方式而是為了在不改變現(xiàn)有交互方式的情況下把不兼容的東西接進來。2. 兩種主流實現(xiàn)方式類適配器與對象適配器2.1 類適配器用繼承實現(xiàn)轉(zhuǎn)換適配器模式在Gof書里分兩種類適配器和對象適配器。類適配器通過繼承來復(fù)用被適配者的代碼它讓適配器同時繼承目標(biāo)接口和被適配類然后在目標(biāo)接口的方法里調(diào)用被適配類的邏輯。直接看代碼會更清楚。還是用上面的支付場景如果用類適配器實現(xiàn)// 目標(biāo)接口訂單模塊依賴的穩(wěn)定接口 public interface PaymentService { void pay(String orderId, double amount); } // 被適配者新的支付SDK public class NewPaySDK { public boolean charge(String bizOrderNo, BigDecimal money, String currency) { // 真實發(fā)起支付 return true; } } // 類適配器繼承SDK實現(xiàn)目標(biāo)接口 public class NewPayAdapter extends NewPaySDK implements PaymentService { Override public void pay(String orderId, double amount) { // 繼承來的 charge 方法在這里被重新包裝 boolean success charge(orderId, BigDecimal.valueOf(amount), CNY); if (!success) { throw new RuntimeException(支付失敗); } } }因為NewPayAdapter繼承了NewPaySDK所以charge()方法是直接繼承過來的不需要額外持有對象代碼看起來非常精簡。這種寫法在C里常見一些因為C支持多繼承一個適配器可以同時繼承接口和被適配類寫起來很順。Java里也可以用代價是只能繼承一個類而且繼承關(guān)系是強耦合的一旦SDK類有改動適配器也要跟著變。類適配器和對象適配器的核心區(qū)別是“復(fù)用方式”。類適配器用繼承對象適配器用組合這是面向?qū)ο笤O(shè)計里老生常談的兩條路線實際開發(fā)中絕大多數(shù)情況下應(yīng)該選組合。2.2 對象適配器用組合實現(xiàn)轉(zhuǎn)換對象適配器不繼承被適配者而是拿著被適配者的引用在目標(biāo)接口的方法內(nèi)部去調(diào)用被適配者的方法。上面那個支付例子重寫成對象適配器是這樣public class NewPayAdapter implements PaymentService { private final NewPaySDK newPaySDK; public NewPayAdapter(NewPaySDK newPaySDK) { this.newPaySDK newPaySDK; } Override public void pay(String orderId, double amount) { boolean success newPaySDK.charge(orderId, BigDecimal.valueOf(amount), CNY); if (!success) { throw new RuntimeException(支付失敗); } } }從實現(xiàn)上看就是構(gòu)造函數(shù)傳入被適配者方法里轉(zhuǎn)一手調(diào)用。但別小看這個區(qū)別。組合的方式讓適配器只依賴接口不依賴SDK的具體類型哪怕SDK內(nèi)部再怎么換實現(xiàn)只要SDK對外方法不變適配器都不用動。另外組合的方式允許適配器同時適配多個被適配者甚至可以在運行期動態(tài)切換繼承做不到這件事。下面這張表可以幫你快速決策對比維度類適配器對象適配器復(fù)用方式繼承被適配類持有被適配對象引用耦合度強約束了被適配類的類型弱面向接口編程靈活性低繼承關(guān)系靜態(tài)固定高可以在運行期動態(tài)切換實現(xiàn)復(fù)雜度簡單代碼少稍微多一點但可讀性更好適用語言C等多繼承語言更方便所有面向?qū)ο笳Z言通用推薦程度只在特殊場景使用絕大多數(shù)場景的首選我自己在實際項目里幾乎沒有用過類適配器Java單繼承限制擺在那里為了接一個SDK犧牲一個繼承位容易后面想擴展時沒地方站。對象適配器雖然多寫幾行構(gòu)造和委托但換來的是“被適配者可以被替換、可以被Mock、可以傳參配置”的靈活性這筆賬怎么算都不虧。3. 一個完整的實戰(zhàn)案例接入第三方支付3.1 需求背景與原始接口前面斷斷續(xù)續(xù)提到了支付場景但真正要理解適配器模式的實操價值還是得看一個完整的上下文。假設(shè)你所在的項目是一個供應(yīng)鏈管理系統(tǒng)里面的訂單模塊從三個業(yè)務(wù)方共用分別是對賬小程序、運營后臺、客戶自助門戶。這三個入口都調(diào)一個公共的支付服務(wù)public interface TradePayService { void pay(String tradeNo, double amount) throws PayException; }如果我說“現(xiàn)在要把底層支付渠道從A換到B”你可能覺得直接換SDK調(diào)用就行。但現(xiàn)實里沒這么簡單渠道B的SDK不只方法名不一樣它對訂單號有格式要求金額只能傳BigDecimal而且有幣種參數(shù)最關(guān)鍵的是它采用回調(diào)確認(rèn)機制pay()方法只是提交預(yù)支付單真正支付成功要等回調(diào)。光憑這一點你那個void pay()的接口就沒法直接映射過去。這時候適配器模式就派上用場了。因為它本質(zhì)上允許你在“目標(biāo)接口不許改”和“被適配者沒法改”兩個約束并存的情況下找到一個中間落點。這里目標(biāo)接口是TradePayService被適配者是渠道B的ChannelBSdk。適配器做的事情包括業(yè)務(wù)訂單號轉(zhuǎn)換成渠道要求的格式、金額類型轉(zhuǎn)換、立即提交預(yù)支付單、返回時把“已受理”解釋成業(yè)務(wù)意義上的“已提交”。代碼結(jié)構(gòu)大概是這樣的// 渠道B的SDK public class ChannelBSdk { public String submitPrepay(String outTradeNo, BigDecimal totalAmount, String currency) { // 返回渠道流水號同時等待異步回調(diào) return CHANNEL_B_20240601XXXX; } } // 適配器 public class ChannelBPayAdapter implements TradePayService { private final ChannelBSdk channelBSdk; public ChannelBPayAdapter(ChannelBSdk channelBSdk) { this.channelBSdk channelBSdk; } Override public void pay(String tradeNo, double amount) throws PayException { // 1. 訂單號轉(zhuǎn)換 String outTradeNo transformTradeNo(tradeNo); // 2. 金額類型轉(zhuǎn)換 BigDecimal targetAmount BigDecimal.valueOf(amount); // 3. 調(diào)用渠道B接口 try { String channelFlowNo channelBSdk.submitPrepay(outTradeNo, targetAmount, CNY); // 4. 把渠道流水號保存起來后續(xù)回調(diào)要用 saveChannelFlowNo(tradeNo, channelFlowNo); } catch (Exception e) { throw new PayException(渠道B支付提交失敗, e); } } private String transformTradeNo(String tradeNo) { // 渠道B要求訂單號必須是數(shù)字且不超過32位這里做脫敏和格式化 return tradeNo.replaceAll([^0-9], ); } }3.2 適配器實現(xiàn)與測試寫適配器不是把代碼塞進去就行它有兩個問題必須處理干凈。第一是異常語義。渠道B的SDK拋出的異常五花八門有網(wǎng)絡(luò)異常、簽名異常、余額不足直接讓它往上拋會讓上層業(yè)務(wù)難以判斷。適配器里要統(tǒng)一轉(zhuǎn)換成業(yè)務(wù)側(cè)異常同時保留原始異常信息這樣崩潰時才能追根溯源。第二是返回值語義。submitPrepay只代表“受理成功”不代表“支付成功”。適配器必須把這兩個概念分開否則訂單系統(tǒng)會因為“提交了”就以為“錢到賬了”后面對賬必然出錯。處理完這兩個問題適配器才能從“接口轉(zhuǎn)換工具”升級成“業(yè)務(wù)邊界清晰的對象”。在真實項目中我會把這種適配器放在獨立的adapter包下并且只依賴目標(biāo)接口和底層SDK不依賴任何上游業(yè)務(wù)邏輯。這樣做的好處是以后渠道B再升級或者出問題我可以單獨替換適配器而不需要動訂單模塊。單元測試也是適配器開發(fā)里很重要的一環(huán)。因為適配器是純轉(zhuǎn)化層是最適合做單測的位置。我通常會Mock掉ChannelBSdk然后驗證適配器是否正確轉(zhuǎn)換參數(shù)、是否拋異常、是否保存了流水號public class ChannelBPayAdapterTest { Test void test_pay_should_convert_params_and_save_flow_no() { ChannelBSdk sdk mock(ChannelBSdk.class); when(sdk.submitPrepay(anyString(), any(), any())).thenReturn(CHANNEL_B_123456); ChannelBPayAdapter adapter new ChannelBPayAdapter(sdk); adapter.pay(ORD20240601-A01, 158.50); verify(sdk).submitPrepay(ORD20240601A01, BigDecimal.valueOf(158.50), CNY); // 再驗證保存流水號的邏輯 verify(flowNoRepository).save(ORD20240601-A01, CHANNEL_B_123456); } }這個測試跑起來不需要任何外部服務(wù)也不需要數(shù)據(jù)庫連真庫。適配器的價值就在這它把一層最容易出錯的轉(zhuǎn)換邏輯獨立出來讓所有業(yè)務(wù)方都在它后面安穩(wěn)工作而你只需要保證這層轉(zhuǎn)換邏輯是正確的。3.3 缺省適配器一種很有用的變體用到真實項目里適配器模式還有一個變體叫缺省適配器Default Adapter很多書本沒細講但實戰(zhàn)里非常實用。場景是這樣的目標(biāo)接口定義了十幾個方法你的業(yè)務(wù)方只關(guān)心其中一兩個如果直接去實現(xiàn)這個接口你被迫寫一堆空方法又丑又容易漏。缺省適配器的做法是先寫一個抽象類把接口里所有方法都實現(xiàn)成空操作或默認(rèn)值讓真正的適配器去繼承這個抽象類只覆寫自己關(guān)心的那部分。Java 8之后有了default方法這個模式的必要性下降了一些但如果你在維護老項目或者目標(biāo)接口是第三方包里的接口不能加default方法缺省適配器依然是很好的過渡手段。比如某舊版回調(diào)接口有onSuccess、onFail、onRetry、onSign、onTimeout五個方法你的業(yè)務(wù)只關(guān)心成功和失敗就可以用一個中間抽象類把后面三個空實現(xiàn)掉具體適配器只覆寫前兩個。代碼可讀性立刻提升不少也不會因為漏實現(xiàn)某個方法導(dǎo)致編譯器報錯后隨便補一個空殼。4. 適配器模式在真實框架里的身影4.1 JDBC就是典型的適配器模式很多教材講適配器模式都會拿JDBCJava Database Connectivity當(dāng)例子。JDBC定義了一套統(tǒng)一的數(shù)據(jù)庫訪問接口比如Connection、Statement、ResultSet數(shù)據(jù)庫廠商負責(zé)提供各自的驅(qū)動實現(xiàn)。你的業(yè)務(wù)代碼只面向JDBC接口寫換來換去只需要改注冊驅(qū)動的類名和URL。這個架構(gòu)里的每個驅(qū)動本質(zhì)上就是一個適配器負責(zé)把MySQL的協(xié)議翻譯成JDBC接口能夠理解的調(diào)用把Oracle的差異封裝在驅(qū)動內(nèi)部。你寫業(yè)務(wù)代碼的人不需要關(guān)心MySQL和Oracle是怎么通信的也不需要關(guān)心它們的SQL方言差異JDBC接口就是那個穩(wěn)定的目標(biāo)接口。JDBC這套設(shè)計之所以能長盛不衰靠的就是適配器模式的核心思想面向穩(wěn)定接口編程變化隔離在驅(qū)動層。如果JDBC直接要求所有數(shù)據(jù)庫廠商提供完全一致的內(nèi)部實現(xiàn)Oracle、MySQL、PostgreSQL早就分道揚鑣了。因為接口穩(wěn)定驅(qū)動可以各自迭代進化這是適配器模式在系統(tǒng)架構(gòu)層面最有說服力的例子。4.2 Spring MVC里的HandlerAdapterSpring MVC里也藏著一個適配器模式的經(jīng)典案例。DispatcherServlet拿到請求后要找到對應(yīng)的Handler來處理。但Handler可以是注解式的Controller方法可以是實現(xiàn)Controller接口的類也可以是HttpRequestHandler甚至可以是Servlet。這幾種類型的方法簽名完全不一樣DispatcherServlet不可能針對每種類型寫死調(diào)用邏輯。于是Spring抽象了一個HandlerAdapter接口每個具體的HandlerAdapterRequestMappingHandlerAdapter、SimpleControllerHandlerAdapter、HttpRequestHandlerAdapter適配一種Handler類型。DispatcherServlet只依賴HandlerAdapter接口通過HandlerMapping找到合適的Adapter再調(diào)用適配器的handle()方法完成請求處理。這個設(shè)計里DispatcherServlet是客戶HandlerAdapter是目標(biāo)接口各種Handler是適配者。每引入一種新的Handler類型只需要新增一個對應(yīng)的HandlerAdapterDispatcherServlet本身完全不需要改。Spring MVC能支撐這么多擴展點離不開這個適配器架構(gòu)。4.3 日志門面與緩存工具中的適配痕跡類似的例子還有日志門面。SLF4J本身不實現(xiàn)日志功能它定義了一套日志接口然后通過slf4j-log4j12、slf4j-simple、logback這些綁定包把不同的日志實現(xiàn)適配到統(tǒng)一接口上。你代碼里只寫LoggerFactory.getLogger(...)底層是logback還是log4j對上層完全透明。這也是適配器模式在開源生態(tài)里最常見的用法。框架里到處都是適配器反倒說明適配器模式不是某種只有面試才會問的“紙面模式”。它的核心價值在于給系統(tǒng)提供一個穩(wěn)定的調(diào)用層讓底層實現(xiàn)可以后續(xù)無限替換。不過要注意框架里的適配器往往比我們自己寫的更復(fù)雜牽扯到生命周期管理、線程模型、異步處理等眾多因素理解框架適配器的思路和直接模仿代碼是兩回事后者需要更多上下文。5. 適配器、外觀模式和代理模式的邊界5.1 三個模式容易混淆的根源很多初學(xué)者會把適配器模式和外觀模式Facade、代理模式Proxy混在一起因為它們都是“多了一層”。這一層里不是隨便寫的每種模式出現(xiàn)的原因和改造的側(cè)重點完全不同。適配器模式的出發(fā)點是接口轉(zhuǎn)換。它解決的是“客戶想要A接口但實際只有B接口且兩邊都不能改”的問題重點是讓不兼容的接口變得兼容。外觀模式的出發(fā)點是簡化調(diào)用。它把一堆復(fù)雜的子系統(tǒng)接口整理成一個簡單的入口重點不是解決兼容性而是降低客戶的使用成本你不需要“轉(zhuǎn)接口”只需要“一鍵調(diào)用”。代理模式的出發(fā)點是控制訪問。代理和被代理對象實現(xiàn)的是同一個接口代理不改變接口而是在調(diào)用前后加一層控制邏輯比如權(quán)限校驗、緩存、懶加載、日志。這三者的區(qū)分可以用一個生活化類比。適配器是電源轉(zhuǎn)換頭接口形狀變了外觀是酒店前臺你不用逐一聯(lián)系客房服務(wù)、餐飲部、維修工給前臺打一個電話就有人去協(xié)調(diào)代理是明星經(jīng)紀(jì)人外界聯(lián)系明星的方式還是打電話但電話先被經(jīng)紀(jì)人接了經(jīng)紀(jì)人在中間決定該不該轉(zhuǎn)接。5.2 實際選型時怎么判斷該用哪一個選型的問題我一般會問自己三個問題。第一客戶期待的接口和現(xiàn)有類提供的接口是不是真的不兼容如果不兼容走適配器。第二客戶是不是被一堆子系統(tǒng)接口搞得暈頭轉(zhuǎn)向我是不是只需要整理一個更友好的門面如果是走外觀模式。第三我要不要在不改接口的前提下控制對某個對象的訪問或者補充一些橫切邏輯如果是走代理模式。最后還有個經(jīng)驗之談適配器模式很容易被濫用成“萬能膠水”。如果一個系統(tǒng)里到處都是適配器每個適配器都在做各種奇怪的轉(zhuǎn)換那你真的要停下來想一想是不是系統(tǒng)本身的接口設(shè)計出了問題。適配器模式有一句經(jīng)典的話“別過度設(shè)計?！碑?dāng)一個系統(tǒng)新來的模塊都要求通過適配器接入而不是每個模塊本身就面向穩(wěn)定的接口分工時適配器已經(jīng)從解決方案變成了技術(shù)債。我見過一個項目因為早期接口設(shè)計太隨意后面接了幾十個適配器來互相轉(zhuǎn)那已經(jīng)不是設(shè)計模式了是打補丁。正確做法是用適配器贏得一段時間然后推動底層接口收斂而不是讓適配器一直躺在那邊“接爛攤子”。6. 適配器模式里的常見坑與排查技巧6.1 接口方法太多導(dǎo)致的適配器臃腫適配器最大的痛點之一是目標(biāo)接口方法太多而適配者根本不關(guān)心其中一大半。Java 8之前寫個適配器要被迫實現(xiàn)所有方法很多人在不需要的方法里拋UnsupportedOperationException或者直接寫空實現(xiàn)結(jié)果后續(xù)調(diào)用某個方法時才發(fā)現(xiàn)沒有真正實現(xiàn)排查半天才看到適配器里躺著一堆空殼。這個問題有幾種解法。如果目標(biāo)是自己的接口優(yōu)先在接口里加default方法處理兜底邏輯如果目標(biāo)是第三方接口用缺省適配器中間層接一下。還有一種思路是拆分接口把大接口拆成多個小接口讓適配器只實現(xiàn)相關(guān)的那部分這樣既符合接口隔離原則也讓適配器本身輕量很多。我自己在重構(gòu)老系統(tǒng)時最喜歡用拆分接口的方式雖然一開始要動的代碼多一些但后期每個適配器的職責(zé)都一目了然。6.2 異常轉(zhuǎn)換丟了原始堆棧適配器在捕獲異常后重新包裝成新異常時很容易犯的一個錯誤是只傳異常信息不傳原始異常對象。比如很多人寫完throw new PayException(渠道B失敗)就結(jié)束了底層SDK拋出的NetworkException的堆棧信息全部丟失線上排查時只能看到一個干巴巴的業(yè)務(wù)異常完全不知道是哪個網(wǎng)絡(luò)環(huán)節(jié)出的問題。正確的寫法是給新異常傳入原始異常作為cause也就是throw new PayException(渠道B支付提交失敗, e)這樣異常鏈才能完整保留。如果你用的異常類沒有帶cause的構(gòu)造函數(shù)把原始異常信息記錄下來也是好的。排查線上問題時一個完整的堆棧鏈能讓你省去至少半小時的瞎猜時間。6.3 適配器嵌套和過度包裝適配器套適配器是我在評審代碼時最頭疼的場景之一。A適配器把第三方SDK轉(zhuǎn)換成內(nèi)部接口B適配器把內(nèi)部接口再轉(zhuǎn)換一次C適配器又加了一層參數(shù)轉(zhuǎn)換三層嵌套下來每個層都有自己的一堆轉(zhuǎn)換規(guī)則代碼完全沒法追蹤出了Bug只能一層一層斷點進去看。適配器模式的初衷是“加一層少改一處”但層數(shù)一旦超過兩層就需要重新審視。大多數(shù)情況下只應(yīng)該有一層適配器去對接外部接口。如果目標(biāo)接口和外部接口差距太大那要先反思自己定義的目標(biāo)接口是不是設(shè)計得有問題而不是靠在外部再加一層適配器來填坑。這里我有個個人經(jīng)驗代碼評審時只要看到超過兩層的適配調(diào)用我基本會提一個重構(gòu)意見哪怕重構(gòu)會引起一些暫時性的改動也好過長期維護一個套娃結(jié)構(gòu)。6.4 適配器真的需要單測嗎很多人覺得適配器只是“轉(zhuǎn)一手”不值得寫單測。這個認(rèn)知恰恰是錯的。適配器是所有轉(zhuǎn)換邏輯匯聚的地方最容易出參數(shù)量級錯誤、空指針、格式問題。我遇到過適配器里漏轉(zhuǎn)了一個字段導(dǎo)致生產(chǎn)環(huán)境的訂單狀態(tài)一直對不上排查了兩天才定位到就是因為那段代碼既沒有人審出問題也沒有測試覆蓋。所以我的建議是適配器必須寫單測而且重點覆蓋幾個點正常參數(shù)轉(zhuǎn)換是否符合預(yù)期、異常情況下是否拋出對應(yīng)異常、邊界值比如金額為0、負數(shù)、超大金額是否處理正確、被適配者的返回值異常時如何應(yīng)對。這些測試寫起來成本很低Mock一下被適配者就行但它們能把適配器從整個鏈路里最不可控的環(huán)節(jié)變成最可靠的環(huán)節(jié)。7. 學(xué)習(xí)適配器模式時的一點個人體會設(shè)計模式這種東西光看書沒有用光背定義更沒用。我在實際項目中真正“開竅”是遇到一個老系統(tǒng)改造任務(wù)。舊系統(tǒng)用一個自己封裝的短信發(fā)送組件接口設(shè)計得亂七八糟新系統(tǒng)要接入阿里云短信和騰訊云短信兩邊參數(shù)格式、重試機制、返回結(jié)果全都不一樣。當(dāng)時我沒有直接改舊接口而是寫了三個適配器分別對應(yīng)舊的短信組件、阿里云SDK和騰訊云SDK。結(jié)果舊系統(tǒng)所有上游服務(wù)一行代碼沒改很輕松就切到了新的短信通道。那個任務(wù)做完之后我才真正理解了適配器模式的價值它不是為了應(yīng)付設(shè)計模式考試而是為了讓你在真實世界里能夠用最小的代價把變化引進來。如果你現(xiàn)在正在準(zhǔn)備考試或者面試我建議你別死記定義先把“接口轉(zhuǎn)換、雙方不動、組合優(yōu)先”這十二個字吃透。然后打開一個真實項目找一個對接外部SDK的入口思考一下如果直接改業(yè)務(wù)流程會有什么后果再試著寫一個適配器把不兼容的部分擋在外面。設(shè)計模式從來不是背出來的是改出來的。適配器尤其如此它看起來簡單但在真實系統(tǒng)里的應(yīng)用深度真的可以差得很遠。 適配器模式實戰(zhàn)：接口轉(zhuǎn)換、對象適配器與第三方支付接入
接手過老項目的人應(yīng)該都有這種體會系統(tǒng)里那些七零八落的接口沒有一個能和你新寫的代碼嚴(yán)絲合縫地對接上改老的怕出事改新的又覺得虧。這時候最穩(wěn)的辦法往往不是強行改某一方的代碼而是在中間加一層“轉(zhuǎn)接頭”讓雙方各干各的互不干擾。這件事放到設(shè)計模式里就是適配器模式Adapter Pattern。我最早接觸這個名字是在大學(xué)里看《Head First 設(shè)計模式》當(dāng)時覺得它不過是“把一個接口轉(zhuǎn)換成另一個接口”而已直到在真實項目里用了幾次才發(fā)現(xiàn)這個模式真正解決的問題不是接口長什么樣而是代碼和代碼之間的關(guān)系怎么處理。這篇文章不打算堆概念我會從為什么需要適配器開始講清楚兩種實現(xiàn)方式的取舍再拿一個接第三方支付的完整例子帶大家走一遍最后聊聊它在框架里的身影、配得上的坑以及和外觀模式、代理模式的邊界。內(nèi)容適合正在學(xué)設(shè)計模式的學(xué)生也適合寫業(yè)務(wù)代碼寫到快崩潰的工程師尤其適合那些想在老系統(tǒng)改造、多廠商對接場景里少走彎路的同學(xué)。1. 適配器模式到底在解決什么問題1.1 從電源插頭說起適配器這個詞其實從生活里來的。你從國外帶回來一個筆記本插頭是歐標(biāo)的兩個圓腳國內(nèi)排插是國標(biāo)的三扁腳或者兩扁腳直接懟進去基本不可能。這時候你不會把墻上的插座拆了重做更不會把筆記本的電源線剪了換頭而是去一趟超市買個轉(zhuǎn)換插頭十幾塊錢插上就能充。設(shè)計模式里的適配器干的就是這件事客戶Client面對的插座是標(biāo)準(zhǔn)接口外部系統(tǒng)Adaptee提供的插頭是另一種規(guī)格適配器Adapter就是中間那個轉(zhuǎn)換頭。它做的事情是讓原本因接口不匹配而無法協(xié)作的類可以一起工作并且在這個過程中雙方都不需要修改自己。放到設(shè)計模式的定義里適配器模式屬于結(jié)構(gòu)型模式結(jié)構(gòu)型模式關(guān)注的核心是“類和對象怎么組合”。組合得好系統(tǒng)就松耦合改A不炸B組合得爛牽一發(fā)而動全身。適配器模式就是為了解決“接口不匹配時的組合問題”而存在的。注意適配器不是萬能的。如果外部系統(tǒng)的行為邏輯和你期望的完全不同光靠接口轉(zhuǎn)換解決不了根本矛盾后面我會講到什么時候不該用適配器。1.2 需求場景與設(shè)計目標(biāo)用代碼場景來描述可能更直接。假設(shè)你現(xiàn)在寫了一個訂單服務(wù)內(nèi)部調(diào)用一個PaymentService接口public interface PaymentService { void pay(String orderId, double amount); }你的業(yè)務(wù)代碼到處都在依賴這個接口方法調(diào)用、參數(shù)類型、返回值全是按這個接口來設(shè)計的。結(jié)果后端突然告訴你公司的支付通道要換新通道SDK提供的接口長這樣public class NewPaySDK { public boolean charge(String bizOrderNo, BigDecimal money, String currency) { // 真實支付邏輯 return true; } }注意這里的問題不只是方法名不一樣還牽扯到了參數(shù)類型String對Long、double對BigDecimal、返回值語義void對boolean、甚至業(yè)務(wù)概念orderId對bizOrderNo。如果你選擇直接改PaymentService和所有調(diào)用方那訂單模塊、支付回調(diào)、對賬邏輯全部要跟著動改完還得全量回歸代價大到離譜。這時候適配器模式的思路就出來了保持PaymentService接口不動寫一個適配器類實現(xiàn)PaymentService內(nèi)部包住NewPaySDK在pay()方法里完成參數(shù)轉(zhuǎn)換和調(diào)用。對外你依然在用原來的接口對內(nèi)你已經(jīng)無縫切到了新SDK。整個過程調(diào)用方一行代碼都不用改。這個例子其實引出了適配器模式最重要的設(shè)計目標(biāo)把“變化的實現(xiàn)”和“穩(wěn)定的接口”隔離開。適配器模式允許你在兩邊都穩(wěn)定的前提下引入變化穩(wěn)定性來自接口不變變化性來自適配器可替換。這是它和很多模式最大的不同——它不是為了設(shè)計出新的交互方式而是為了在不改變現(xiàn)有交互方式的情況下把不兼容的東西接進來。2. 兩種主流實現(xiàn)方式類適配器與對象適配器2.1 類適配器用繼承實現(xiàn)轉(zhuǎn)換適配器模式在Gof書里分兩種類適配器和對象適配器。類適配器通過繼承來復(fù)用被適配者的代碼它讓適配器同時繼承目標(biāo)接口和被適配類然后在目標(biāo)接口的方法里調(diào)用被適配類的邏輯。直接看代碼會更清楚。還是用上面的支付場景如果用類適配器實現(xiàn)// 目標(biāo)接口訂單模塊依賴的穩(wěn)定接口 public interface PaymentService { void pay(String orderId, double amount); } // 被適配者新的支付SDK public class NewPaySDK { public boolean charge(String bizOrderNo, BigDecimal money, String currency) { // 真實發(fā)起支付 return true; } } // 類適配器繼承SDK實現(xiàn)目標(biāo)接口 public class NewPayAdapter extends NewPaySDK implements PaymentService { Override public void pay(String orderId, double amount) { // 繼承來的 charge 方法在這里被重新包裝 boolean success charge(orderId, BigDecimal.valueOf(amount), CNY); if (!success) { throw new RuntimeException(支付失敗); } } }因為NewPayAdapter繼承了NewPaySDK所以charge()方法是直接繼承過來的不需要額外持有對象代碼看起來非常精簡。這種寫法在C里常見一些因為C支持多繼承一個適配器可以同時繼承接口和被適配類寫起來很順。Java里也可以用代價是只能繼承一個類而且繼承關(guān)系是強耦合的一旦SDK類有改動適配器也要跟著變。類適配器和對象適配器的核心區(qū)別是“復(fù)用方式”。類適配器用繼承對象適配器用組合這是面向?qū)ο笤O(shè)計里老生常談的兩條路線實際開發(fā)中絕大多數(shù)情況下應(yīng)該選組合。2.2 對象適配器用組合實現(xiàn)轉(zhuǎn)換對象適配器不繼承被適配者而是拿著被適配者的引用在目標(biāo)接口的方法內(nèi)部去調(diào)用被適配者的方法。上面那個支付例子重寫成對象適配器是這樣public class NewPayAdapter implements PaymentService { private final NewPaySDK newPaySDK; public NewPayAdapter(NewPaySDK newPaySDK) { this.newPaySDK newPaySDK; } Override public void pay(String orderId, double amount) { boolean success newPaySDK.charge(orderId, BigDecimal.valueOf(amount), CNY); if (!success) { throw new RuntimeException(支付失敗); } } }從實現(xiàn)上看就是構(gòu)造函數(shù)傳入被適配者方法里轉(zhuǎn)一手調(diào)用。但別小看這個區(qū)別。組合的方式讓適配器只依賴接口不依賴SDK的具體類型哪怕SDK內(nèi)部再怎么換實現(xiàn)只要SDK對外方法不變適配器都不用動。另外組合的方式允許適配器同時適配多個被適配者甚至可以在運行期動態(tài)切換繼承做不到這件事。下面這張表可以幫你快速決策對比維度類適配器對象適配器復(fù)用方式繼承被適配類持有被適配對象引用耦合度強約束了被適配類的類型弱面向接口編程靈活性低繼承關(guān)系靜態(tài)固定高可以在運行期動態(tài)切換實現(xiàn)復(fù)雜度簡單代碼少稍微多一點但可讀性更好適用語言C等多繼承語言更方便所有面向?qū)ο笳Z言通用推薦程度只在特殊場景使用絕大多數(shù)場景的首選我自己在實際項目里幾乎沒有用過類適配器Java單繼承限制擺在那里為了接一個SDK犧牲一個繼承位容易后面想擴展時沒地方站。對象適配器雖然多寫幾行構(gòu)造和委托但換來的是“被適配者可以被替換、可以被Mock、可以傳參配置”的靈活性這筆賬怎么算都不虧。3. 一個完整的實戰(zhàn)案例接入第三方支付3.1 需求背景與原始接口前面斷斷續(xù)續(xù)提到了支付場景但真正要理解適配器模式的實操價值還是得看一個完整的上下文。假設(shè)你所在的項目是一個供應(yīng)鏈管理系統(tǒng)里面的訂單模塊從三個業(yè)務(wù)方共用分別是對賬小程序、運營后臺、客戶自助門戶。這三個入口都調(diào)一個公共的支付服務(wù)public interface TradePayService { void pay(String tradeNo, double amount) throws PayException; }如果我說“現(xiàn)在要把底層支付渠道從A換到B”你可能覺得直接換SDK調(diào)用就行。但現(xiàn)實里沒這么簡單渠道B的SDK不只方法名不一樣它對訂單號有格式要求金額只能傳BigDecimal而且有幣種參數(shù)最關(guān)鍵的是它采用回調(diào)確認(rèn)機制pay()方法只是提交預(yù)支付單真正支付成功要等回調(diào)。光憑這一點你那個void pay()的接口就沒法直接映射過去。這時候適配器模式就派上用場了。因為它本質(zhì)上允許你在“目標(biāo)接口不許改”和“被適配者沒法改”兩個約束并存的情況下找到一個中間落點。這里目標(biāo)接口是TradePayService被適配者是渠道B的ChannelBSdk。適配器做的事情包括業(yè)務(wù)訂單號轉(zhuǎn)換成渠道要求的格式、金額類型轉(zhuǎn)換、立即提交預(yù)支付單、返回時把“已受理”解釋成業(yè)務(wù)意義上的“已提交”。代碼結(jié)構(gòu)大概是這樣的// 渠道B的SDK public class ChannelBSdk { public String submitPrepay(String outTradeNo, BigDecimal totalAmount, String currency) { // 返回渠道流水號同時等待異步回調(diào) return CHANNEL_B_20240601XXXX; } } // 適配器 public class ChannelBPayAdapter implements TradePayService { private final ChannelBSdk channelBSdk; public ChannelBPayAdapter(ChannelBSdk channelBSdk) { this.channelBSdk channelBSdk; } Override public void pay(String tradeNo, double amount) throws PayException { // 1. 訂單號轉(zhuǎn)換 String outTradeNo transformTradeNo(tradeNo); // 2. 金額類型轉(zhuǎn)換 BigDecimal targetAmount BigDecimal.valueOf(amount); // 3. 調(diào)用渠道B接口 try { String channelFlowNo channelBSdk.submitPrepay(outTradeNo, targetAmount, CNY); // 4. 把渠道流水號保存起來后續(xù)回調(diào)要用 saveChannelFlowNo(tradeNo, channelFlowNo); } catch (Exception e) { throw new PayException(渠道B支付提交失敗, e); } } private String transformTradeNo(String tradeNo) { // 渠道B要求訂單號必須是數(shù)字且不超過32位這里做脫敏和格式化 return tradeNo.replaceAll([^0-9], ); } }3.2 適配器實現(xiàn)與測試寫適配器不是把代碼塞進去就行它有兩個問題必須處理干凈。第一是異常語義。渠道B的SDK拋出的異常五花八門有網(wǎng)絡(luò)異常、簽名異常、余額不足直接讓它往上拋會讓上層業(yè)務(wù)難以判斷。適配器里要統(tǒng)一轉(zhuǎn)換成業(yè)務(wù)側(cè)異常同時保留原始異常信息這樣崩潰時才能追根溯源。第二是返回值語義。submitPrepay只代表“受理成功”不代表“支付成功”。適配器必須把這兩個概念分開否則訂單系統(tǒng)會因為“提交了”就以為“錢到賬了”后面對賬必然出錯。處理完這兩個問題適配器才能從“接口轉(zhuǎn)換工具”升級成“業(yè)務(wù)邊界清晰的對象”。在真實項目中我會把這種適配器放在獨立的adapter包下并且只依賴目標(biāo)接口和底層SDK不依賴任何上游業(yè)務(wù)邏輯。這樣做的好處是以后渠道B再升級或者出問題我可以單獨替換適配器而不需要動訂單模塊。單元測試也是適配器開發(fā)里很重要的一環(huán)。因為適配器是純轉(zhuǎn)化層是最適合做單測的位置。我通常會Mock掉ChannelBSdk然后驗證適配器是否正確轉(zhuǎn)換參數(shù)、是否拋異常、是否保存了流水號public class ChannelBPayAdapterTest { Test void test_pay_should_convert_params_and_save_flow_no() { ChannelBSdk sdk mock(ChannelBSdk.class); when(sdk.submitPrepay(anyString(), any(), any())).thenReturn(CHANNEL_B_123456); ChannelBPayAdapter adapter new ChannelBPayAdapter(sdk); adapter.pay(ORD20240601-A01, 158.50); verify(sdk).submitPrepay(ORD20240601A01, BigDecimal.valueOf(158.50), CNY); // 再驗證保存流水號的邏輯 verify(flowNoRepository).save(ORD20240601-A01, CHANNEL_B_123456); } }這個測試跑起來不需要任何外部服務(wù)也不需要數(shù)據(jù)庫連真庫。適配器的價值就在這它把一層最容易出錯的轉(zhuǎn)換邏輯獨立出來讓所有業(yè)務(wù)方都在它后面安穩(wěn)工作而你只需要保證這層轉(zhuǎn)換邏輯是正確的。3.3 缺省適配器一種很有用的變體用到真實項目里適配器模式還有一個變體叫缺省適配器Default Adapter很多書本沒細講但實戰(zhàn)里非常實用。場景是這樣的目標(biāo)接口定義了十幾個方法你的業(yè)務(wù)方只關(guān)心其中一兩個如果直接去實現(xiàn)這個接口你被迫寫一堆空方法又丑又容易漏。缺省適配器的做法是先寫一個抽象類把接口里所有方法都實現(xiàn)成空操作或默認(rèn)值讓真正的適配器去繼承這個抽象類只覆寫自己關(guān)心的那部分。Java 8之后有了default方法這個模式的必要性下降了一些但如果你在維護老項目或者目標(biāo)接口是第三方包里的接口不能加default方法缺省適配器依然是很好的過渡手段。比如某舊版回調(diào)接口有onSuccess、onFail、onRetry、onSign、onTimeout五個方法你的業(yè)務(wù)只關(guān)心成功和失敗就可以用一個中間抽象類把后面三個空實現(xiàn)掉具體適配器只覆寫前兩個。代碼可讀性立刻提升不少也不會因為漏實現(xiàn)某個方法導(dǎo)致編譯器報錯后隨便補一個空殼。4. 適配器模式在真實框架里的身影4.1 JDBC就是典型的適配器模式很多教材講適配器模式都會拿JDBCJava Database Connectivity當(dāng)例子。JDBC定義了一套統(tǒng)一的數(shù)據(jù)庫訪問接口比如Connection、Statement、ResultSet數(shù)據(jù)庫廠商負責(zé)提供各自的驅(qū)動實現(xiàn)。你的業(yè)務(wù)代碼只面向JDBC接口寫換來換去只需要改注冊驅(qū)動的類名和URL。這個架構(gòu)里的每個驅(qū)動本質(zhì)上就是一個適配器負責(zé)把MySQL的協(xié)議翻譯成JDBC接口能夠理解的調(diào)用把Oracle的差異封裝在驅(qū)動內(nèi)部。你寫業(yè)務(wù)代碼的人不需要關(guān)心MySQL和Oracle是怎么通信的也不需要關(guān)心它們的SQL方言差異JDBC接口就是那個穩(wěn)定的目標(biāo)接口。JDBC這套設(shè)計之所以能長盛不衰靠的就是適配器模式的核心思想面向穩(wěn)定接口編程變化隔離在驅(qū)動層。如果JDBC直接要求所有數(shù)據(jù)庫廠商提供完全一致的內(nèi)部實現(xiàn)Oracle、MySQL、PostgreSQL早就分道揚鑣了。因為接口穩(wěn)定驅(qū)動可以各自迭代進化這是適配器模式在系統(tǒng)架構(gòu)層面最有說服力的例子。4.2 Spring MVC里的HandlerAdapterSpring MVC里也藏著一個適配器模式的經(jīng)典案例。DispatcherServlet拿到請求后要找到對應(yīng)的Handler來處理。但Handler可以是注解式的Controller方法可以是實現(xiàn)Controller接口的類也可以是HttpRequestHandler甚至可以是Servlet。這幾種類型的方法簽名完全不一樣DispatcherServlet不可能針對每種類型寫死調(diào)用邏輯。于是Spring抽象了一個HandlerAdapter接口每個具體的HandlerAdapterRequestMappingHandlerAdapter、SimpleControllerHandlerAdapter、HttpRequestHandlerAdapter適配一種Handler類型。DispatcherServlet只依賴HandlerAdapter接口通過HandlerMapping找到合適的Adapter再調(diào)用適配器的handle()方法完成請求處理。這個設(shè)計里DispatcherServlet是客戶HandlerAdapter是目標(biāo)接口各種Handler是適配者。每引入一種新的Handler類型只需要新增一個對應(yīng)的HandlerAdapterDispatcherServlet本身完全不需要改。Spring MVC能支撐這么多擴展點離不開這個適配器架構(gòu)。4.3 日志門面與緩存工具中的適配痕跡類似的例子還有日志門面。SLF4J本身不實現(xiàn)日志功能它定義了一套日志接口然后通過slf4j-log4j12、slf4j-simple、logback這些綁定包把不同的日志實現(xiàn)適配到統(tǒng)一接口上。你代碼里只寫LoggerFactory.getLogger(...)底層是logback還是log4j對上層完全透明。這也是適配器模式在開源生態(tài)里最常見的用法。框架里到處都是適配器反倒說明適配器模式不是某種只有面試才會問的“紙面模式”。它的核心價值在于給系統(tǒng)提供一個穩(wěn)定的調(diào)用層讓底層實現(xiàn)可以后續(xù)無限替換。不過要注意框架里的適配器往往比我們自己寫的更復(fù)雜牽扯到生命周期管理、線程模型、異步處理等眾多因素理解框架適配器的思路和直接模仿代碼是兩回事后者需要更多上下文。5. 適配器、外觀模式和代理模式的邊界5.1 三個模式容易混淆的根源很多初學(xué)者會把適配器模式和外觀模式Facade、代理模式Proxy混在一起因為它們都是“多了一層”。這一層里不是隨便寫的每種模式出現(xiàn)的原因和改造的側(cè)重點完全不同。適配器模式的出發(fā)點是接口轉(zhuǎn)換。它解決的是“客戶想要A接口但實際只有B接口且兩邊都不能改”的問題重點是讓不兼容的接口變得兼容。外觀模式的出發(fā)點是簡化調(diào)用。它把一堆復(fù)雜的子系統(tǒng)接口整理成一個簡單的入口重點不是解決兼容性而是降低客戶的使用成本你不需要“轉(zhuǎn)接口”只需要“一鍵調(diào)用”。代理模式的出發(fā)點是控制訪問。代理和被代理對象實現(xiàn)的是同一個接口代理不改變接口而是在調(diào)用前后加一層控制邏輯比如權(quán)限校驗、緩存、懶加載、日志。這三者的區(qū)分可以用一個生活化類比。適配器是電源轉(zhuǎn)換頭接口形狀變了外觀是酒店前臺你不用逐一聯(lián)系客房服務(wù)、餐飲部、維修工給前臺打一個電話就有人去協(xié)調(diào)代理是明星經(jīng)紀(jì)人外界聯(lián)系明星的方式還是打電話但電話先被經(jīng)紀(jì)人接了經(jīng)紀(jì)人在中間決定該不該轉(zhuǎn)接。5.2 實際選型時怎么判斷該用哪一個選型的問題我一般會問自己三個問題。第一客戶期待的接口和現(xiàn)有類提供的接口是不是真的不兼容如果不兼容走適配器。第二客戶是不是被一堆子系統(tǒng)接口搞得暈頭轉(zhuǎn)向我是不是只需要整理一個更友好的門面如果是走外觀模式。第三我要不要在不改接口的前提下控制對某個對象的訪問或者補充一些橫切邏輯如果是走代理模式。最后還有個經(jīng)驗之談適配器模式很容易被濫用成“萬能膠水”。如果一個系統(tǒng)里到處都是適配器每個適配器都在做各種奇怪的轉(zhuǎn)換那你真的要停下來想一想是不是系統(tǒng)本身的接口設(shè)計出了問題。適配器模式有一句經(jīng)典的話“別過度設(shè)計?！碑?dāng)一個系統(tǒng)新來的模塊都要求通過適配器接入而不是每個模塊本身就面向穩(wěn)定的接口分工時適配器已經(jīng)從解決方案變成了技術(shù)債。我見過一個項目因為早期接口設(shè)計太隨意后面接了幾十個適配器來互相轉(zhuǎn)那已經(jīng)不是設(shè)計模式了是打補丁。正確做法是用適配器贏得一段時間然后推動底層接口收斂而不是讓適配器一直躺在那邊“接爛攤子”。6. 適配器模式里的常見坑與排查技巧6.1 接口方法太多導(dǎo)致的適配器臃腫適配器最大的痛點之一是目標(biāo)接口方法太多而適配者根本不關(guān)心其中一大半。Java 8之前寫個適配器要被迫實現(xiàn)所有方法很多人在不需要的方法里拋UnsupportedOperationException或者直接寫空實現(xiàn)結(jié)果后續(xù)調(diào)用某個方法時才發(fā)現(xiàn)沒有真正實現(xiàn)排查半天才看到適配器里躺著一堆空殼。這個問題有幾種解法。如果目標(biāo)是自己的接口優(yōu)先在接口里加default方法處理兜底邏輯如果目標(biāo)是第三方接口用缺省適配器中間層接一下。還有一種思路是拆分接口把大接口拆成多個小接口讓適配器只實現(xiàn)相關(guān)的那部分這樣既符合接口隔離原則也讓適配器本身輕量很多。我自己在重構(gòu)老系統(tǒng)時最喜歡用拆分接口的方式雖然一開始要動的代碼多一些但后期每個適配器的職責(zé)都一目了然。6.2 異常轉(zhuǎn)換丟了原始堆棧適配器在捕獲異常后重新包裝成新異常時很容易犯的一個錯誤是只傳異常信息不傳原始異常對象。比如很多人寫完throw new PayException(渠道B失敗)就結(jié)束了底層SDK拋出的NetworkException的堆棧信息全部丟失線上排查時只能看到一個干巴巴的業(yè)務(wù)異常完全不知道是哪個網(wǎng)絡(luò)環(huán)節(jié)出的問題。正確的寫法是給新異常傳入原始異常作為cause也就是throw new PayException(渠道B支付提交失敗, e)這樣異常鏈才能完整保留。如果你用的異常類沒有帶cause的構(gòu)造函數(shù)把原始異常信息記錄下來也是好的。排查線上問題時一個完整的堆棧鏈能讓你省去至少半小時的瞎猜時間。6.3 適配器嵌套和過度包裝適配器套適配器是我在評審代碼時最頭疼的場景之一。A適配器把第三方SDK轉(zhuǎn)換成內(nèi)部接口B適配器把內(nèi)部接口再轉(zhuǎn)換一次C適配器又加了一層參數(shù)轉(zhuǎn)換三層嵌套下來每個層都有自己的一堆轉(zhuǎn)換規(guī)則代碼完全沒法追蹤出了Bug只能一層一層斷點進去看。適配器模式的初衷是“加一層少改一處”但層數(shù)一旦超過兩層就需要重新審視。大多數(shù)情況下只應(yīng)該有一層適配器去對接外部接口。如果目標(biāo)接口和外部接口差距太大那要先反思自己定義的目標(biāo)接口是不是設(shè)計得有問題而不是靠在外部再加一層適配器來填坑。這里我有個個人經(jīng)驗代碼評審時只要看到超過兩層的適配調(diào)用我基本會提一個重構(gòu)意見哪怕重構(gòu)會引起一些暫時性的改動也好過長期維護一個套娃結(jié)構(gòu)。6.4 適配器真的需要單測嗎很多人覺得適配器只是“轉(zhuǎn)一手”不值得寫單測。這個認(rèn)知恰恰是錯的。適配器是所有轉(zhuǎn)換邏輯匯聚的地方最容易出參數(shù)量級錯誤、空指針、格式問題。我遇到過適配器里漏轉(zhuǎn)了一個字段導(dǎo)致生產(chǎn)環(huán)境的訂單狀態(tài)一直對不上排查了兩天才定位到就是因為那段代碼既沒有人審出問題也沒有測試覆蓋。所以我的建議是適配器必須寫單測而且重點覆蓋幾個點正常參數(shù)轉(zhuǎn)換是否符合預(yù)期、異常情況下是否拋出對應(yīng)異常、邊界值比如金額為0、負數(shù)、超大金額是否處理正確、被適配者的返回值異常時如何應(yīng)對。這些測試寫起來成本很低Mock一下被適配者就行但它們能把適配器從整個鏈路里最不可控的環(huán)節(jié)變成最可靠的環(huán)節(jié)。7. 學(xué)習(xí)適配器模式時的一點個人體會設(shè)計模式這種東西光看書沒有用光背定義更沒用。我在實際項目中真正“開竅”是遇到一個老系統(tǒng)改造任務(wù)。舊系統(tǒng)用一個自己封裝的短信發(fā)送組件接口設(shè)計得亂七八糟新系統(tǒng)要接入阿里云短信和騰訊云短信兩邊參數(shù)格式、重試機制、返回結(jié)果全都不一樣。當(dāng)時我沒有直接改舊接口而是寫了三個適配器分別對應(yīng)舊的短信組件、阿里云SDK和騰訊云SDK。結(jié)果舊系統(tǒng)所有上游服務(wù)一行代碼沒改很輕松就切到了新的短信通道。那個任務(wù)做完之后我才真正理解了適配器模式的價值它不是為了應(yīng)付設(shè)計模式考試而是為了讓你在真實世界里能夠用最小的代價把變化引進來。如果你現(xiàn)在正在準(zhǔn)備考試或者面試我建議你別死記定義先把“接口轉(zhuǎn)換、雙方不動、組合優(yōu)先”這十二個字吃透。然后打開一個真實項目找一個對接外部SDK的入口思考一下如果直接改業(yè)務(wù)流程會有什么后果再試著寫一個適配器把不兼容的部分擋在外面。設(shè)計模式從來不是背出來的是改出來的。適配器尤其如此它看起來簡單但在真實系統(tǒng)里的應(yīng)用深度真的可以差得很遠。