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