裝配：重構(gòu)支付回調(diào)if-else的完整實(shí)踐)
不知道你有沒有接過那種看起來很簡(jiǎn)單一打開就想關(guān)掉的老接口。我最近重構(gòu)一個(gè)支付回調(diào)服務(wù)里面那個(gè)分發(fā)方法一共 200 多行七八個(gè)if (channel.equals(...))分支挨個(gè)堆積每個(gè)分支里還各自牽扯對(duì)賬、狀態(tài)更新、消息推送。每次新對(duì)接一個(gè)渠道我都要在別人寫了幾年的代碼里找到那個(gè)方法小心翼翼地把新分支塞進(jìn)去生怕動(dòng)錯(cuò)一個(gè)括號(hào)。改完之后代碼評(píng)審時(shí)同事問了一句這方法怎么又變長(zhǎng)了我一時(shí)語塞就是因?yàn)檫@句話我下決心把這塊改造成策略模式 Spring 自動(dòng)裝配的方案。這篇文章就完整記錄我從為什么要改、怎么設(shè)計(jì)到實(shí)際重構(gòu)、踩坑收尾的全過程給同樣被 if-else 支配的朋友一條可以直接照抄的路線。1. 被 if-else 支配的回調(diào)分發(fā)先看清痛點(diǎn)到底在哪1.1 一段典型的分支堆砌代碼長(zhǎng)什么樣業(yè)務(wù)背景很樸素系統(tǒng)需要接收不同第三方支付渠道的回調(diào)有支付寶、微信、銀聯(lián)后續(xù)還要接京東、抖音支付。每個(gè)渠道的回調(diào)報(bào)文格式不一樣、驗(yàn)簽邏輯不一樣、入賬處理也不一樣。最初版本只支持支付寶后來微信接入直接在原方法上追加else if再后來銀聯(lián)也接入繼續(xù)追加。等我要接第四個(gè)渠道時(shí)代碼已經(jīng)長(zhǎng)成這樣public CallbackResult handleCallback(String channel, CallbackRequest request) { if (alipay.equals(channel)) { AlipayBiz alipayBiz new AlipayBiz(); if (!alipayBiz.verifySign(request.getParams())) { throw new BizException(支付寶驗(yàn)簽失敗); } String orderNo alipayBiz.getOrderNo(request.getParams()); Order order orderService.getByOrderNo(orderNo); // 更新訂單狀態(tài)、處理商品邏輯、發(fā)送站內(nèi)通知... // 中間還有幾十行業(yè)務(wù)代碼 return CallbackResult.success(); } else if (wechat.equals(channel)) { WechatBiz wechatBiz new WechatBiz(); if (!wechatBiz.verifySign(request.getParams())) { throw new BizException(微信驗(yàn)簽失敗); } // 又是一大段幾乎沒有復(fù)用性的邏輯 return CallbackResult.success(); } else if (unionpay.equals(channel)) { // 第三個(gè)渠道邏輯繼續(xù)復(fù)制粘貼 } else { throw new BizException(不支持的渠道); } }這段代碼表面上是能用實(shí)際上四個(gè)問題一個(gè)比一個(gè)致命第一可讀性極差。200 行方法從頭到尾沒有分節(jié)核心業(yè)務(wù)邏輯完全淹沒在渠道判斷里。新同事接手時(shí)根本分不清哪些代碼是公共流程、哪些是渠道差異邏輯連定位一個(gè) bug 都要來回滾動(dòng)看半天。第二擴(kuò)展成本高。每加一個(gè)渠道就要改動(dòng)這個(gè)老方法而改一個(gè)每天都在線上跑的入口方法心理壓力是巨大的。代碼越加越長(zhǎng)回歸測(cè)試的范圍也越來越大因?yàn)楦膭?dòng)的位置太中心了誰都不敢保證動(dòng)一個(gè)分支會(huì)不會(huì)影響另一個(gè)分支。第三可測(cè)試性幾乎為零。想測(cè)試第四個(gè)渠道的邏輯得先跑完前三個(gè)分支的條件判斷。想單獨(dú)驗(yàn)證支付寶的驗(yàn)簽邏輯抱歉你得構(gòu)造整個(gè)handleCallback的調(diào)用鏈路連微信和銀聯(lián)的分支代碼也會(huì)被加載進(jìn)測(cè)試覆蓋率里。第四很難復(fù)用。如果未來有其他接口比如主動(dòng)查單、退款回調(diào)也要按渠道分發(fā)這段邏輯無法被復(fù)用只能再次復(fù)制一份然后繼續(xù)膨脹。這種代碼不是 爛代碼 那么簡(jiǎn)單它是一個(gè)會(huì)讓團(tuán)隊(duì)整體效率不斷下降的壞味道。而且我要強(qiáng)調(diào)用 switch-case 替換 if-else 解決不了本質(zhì)問題因?yàn)榉种袛嗪蜆I(yè)務(wù)邏輯仍然強(qiáng)耦合在一個(gè)方法里。哪怕寫成 switch每加一個(gè) case 仍然要?jiǎng)舆@個(gè)方法。1.2 為什么很多人知道策略模式卻照樣寫不好有人說策略模式嘛誰不會(huì)。但我在代碼評(píng)審里見過太多次偽策略模式——名義上建了策略接口實(shí)際干的事情并沒有解決問題。最常見的三種變形變形一策略類內(nèi)部繼續(xù) if-else。把所有渠道處理邏輯塞到一個(gè)大工廠類里工廠類的getHandler(channel)方法依然是 8 個(gè)條件判斷。這只是把 if-else 從方法里挪到了工廠里換湯不換藥。變形二手動(dòng)維護(hù)策略注冊(cè)表。知道要用 Map于是寫一個(gè)static MapString, Handler然后在每個(gè)實(shí)現(xiàn)類的靜態(tài)代碼塊里put(alipay, this)或者在一個(gè)集中配置類里手動(dòng) new 出來再 put。這樣搞的問題在于策略實(shí)例的生命周期完全靠自己管理Spring 的依賴注入、AOP、代理這些能力全都浪費(fèi)了而且很容易出現(xiàn)忘記注冊(cè)導(dǎo)致運(yùn)行時(shí) NPE。變形三用反射或字符串拼接去做動(dòng)態(tài)分發(fā)。比如根據(jù) channel 拼出類名然后Class.forName反射調(diào)用。這種方案看起來巧妙實(shí)際上把類型安全徹底丟掉了類名一重構(gòu)就全盤崩性能也受影響排查問題非常費(fèi)勁。真正正確的姿勢(shì)是什么就是利用 Spring 容器自己的自動(dòng)裝配能力把每個(gè)渠道的處理邏輯做成一個(gè)獨(dú)立的 Spring Bean然后讓 Spring 把同一接口下的所有實(shí)現(xiàn)類收集起來自動(dòng)組裝成一個(gè) Map。調(diào)用方一行代碼從 Map 里取出對(duì)應(yīng)策略甚至不需要關(guān)心到底有哪些策略實(shí)現(xiàn)類存在。這個(gè)思路的核心轉(zhuǎn)變是——選擇權(quán)從調(diào)用方代碼轉(zhuǎn)移到了IoC 容器。2. 策略模式在 Spring 里的正確打開方式核心是讓容器替你完成選擇2.1 經(jīng)典策略模式與 Spring 容器策略模式的差異先回憶一下經(jīng)典策略模式的教科書寫法有一個(gè)策略接口多個(gè)具體策略實(shí)現(xiàn)類然后一個(gè) Context 類持有策略接口引用客戶端在調(diào)用時(shí)手動(dòng)選擇具體策略傳入 Context。核心思想是把算法獨(dú)立封裝使它們可以互相替換。到了 Spring 項(xiàng)目里這個(gè)模式有一個(gè)天然的升級(jí)版具體策略實(shí)現(xiàn)類交給 Spring 管理成為 Bean然后通過集合注入把容器內(nèi)所有策略接口的實(shí)現(xiàn)類自動(dòng)收集起來。調(diào)用方不再選擇策略而是把選擇條件交給 Spring 裝配的結(jié)果——一個(gè)以渠道標(biāo)識(shí)為 key 的 Map。很多人第一次看到這種寫法時(shí)會(huì)覺得奇怪Map 也能注入這里要展開說說因?yàn)檫@是整個(gè)方案里的關(guān)鍵點(diǎn)也是很多人實(shí)際用錯(cuò)的環(huán)節(jié)。2.2 Map 注入與 List 注入Spring 集合注入能力的兩種用法Spring 允許在注入點(diǎn)直接聲明一個(gè)接口類型的集合比如Component public class PaymentDispatcher { private final MapString, CallbackHandler handlerMap; public PaymentDispatcher(MapString, CallbackHandler handlerMap) { this.handlerMap handlerMap; } }啟動(dòng)時(shí) Spring 會(huì)掃描容器中所有CallbackHandler接口的實(shí)現(xiàn)類 Bean把它們按照beanName 作為 key、實(shí)例作為 value的方式組裝成一個(gè)MapString, CallbackHandler注入進(jìn)來。如果用 Listprivate final ListCallbackHandler handlers;那就得到一個(gè)包含所有實(shí)現(xiàn)類的 List順序可以通過Order注解或?qū)崿F(xiàn)Ordered接口來控制。這里有兩個(gè)非常容易踩的細(xì)節(jié)第一個(gè)細(xì)節(jié)Map 的 key 默認(rèn)是 Bean 的名字不是實(shí)現(xiàn)類上的任何自定義標(biāo)識(shí)。如果你的實(shí)現(xiàn)類叫AlipayCallbackHandler那么默認(rèn) key 是alipayCallbackHandler首字母小寫而不是alipay。如果你調(diào)用時(shí)handlerMap.get(alipay)拿到的就是 null。這就是很多人第一次改造失敗的直接原因。第二個(gè)細(xì)節(jié)Map 注入不會(huì)觸發(fā)類型轉(zhuǎn)換或排序。Spring 會(huì)把所有匹配類型的 Bean 一次性收集進(jìn) Map如果你希望按特定的規(guī)則排列得自己在策略接口上設(shè)計(jì)優(yōu)先級(jí)的概念或者使用Order配合 List 使用。聊清楚這兩點(diǎn)之后你就可以看出來策略模式 Spring 自動(dòng)裝配的核心套路其實(shí)非常簡(jiǎn)潔定義策略接口接口方法就是業(yè)務(wù)處理的統(tǒng)一入口。每個(gè)分支邏輯寫成一個(gè)實(shí)現(xiàn)類注冊(cè)為 Spring Bean。用一個(gè)分發(fā)器Dispatcher / Holder注入策略 Map。調(diào)用方只依賴分發(fā)器傳入業(yè)務(wù)類型標(biāo)識(shí)拿到對(duì)應(yīng)策略實(shí)例。擴(kuò)展新渠道時(shí)只新增一個(gè)策略 Bean其他代碼完全不動(dòng)。這個(gè)套路比手動(dòng)寫工廠的優(yōu)雅之處在于注冊(cè)動(dòng)作由容器完成天然避免了忘了 put 的問題。Spring 容器本身就是最大的工廠你只要把實(shí)現(xiàn)類定義成 Bean它就自動(dòng)進(jìn)了 Map。2.3 為什么推薦構(gòu)造函數(shù)注入而不是字段注入在 Spring 策略集合注入的寫法里我強(qiáng)烈建議用構(gòu)造函數(shù)注入而且用final修飾字段。除了 Spring 官方推薦的不可變依賴原則之外在策略分發(fā)器這個(gè)特定場(chǎng)景里還有兩個(gè)實(shí)際收益防止空指針。如果一個(gè)環(huán)節(jié)你忘了聲明構(gòu)造參數(shù)Spring 啟動(dòng)時(shí)直接報(bào)錯(cuò)而不是運(yùn)行到某次調(diào)用時(shí)才發(fā)現(xiàn) handlerMap 是 null。方便單元測(cè)試。構(gòu)造函數(shù)注入意味著你可以直接new PaymentDispatcher(Map.of(alipay, mockHandler))來構(gòu)造測(cè)試對(duì)象不需要啟動(dòng) Spring 容器。我在項(xiàng)目里用 Lombok 的RequiredArgsConstructor配合final字段代碼非常干凈這也是目前 Spring Boot 項(xiàng)目里最主流的寫法。3. 重構(gòu)全過程從三大渠道 if-else 到策略分發(fā)器配完整代碼3.1 先定義策略接口想清楚變化的是什么回到支付回調(diào)的例子。重構(gòu)的第一步不是寫實(shí)現(xiàn)類而是想清楚一個(gè)問題這段代碼里什么東西是穩(wěn)定的什么東西是變化的穩(wěn)定的是整個(gè)回調(diào)處理的流程骨架——驗(yàn)簽、取訂單號(hào)、更新狀態(tài)、返回結(jié)果。 變化的是每個(gè)渠道的驗(yàn)簽方式、報(bào)文解析方式、可能還有一些不同的業(yè)務(wù)規(guī)則。策略接口就把變化的部分統(tǒng)一成一個(gè)方法簽名。在這個(gè)場(chǎng)景里我定義接口如下public interface CallbackHandler { String getChannel(); CallbackResult process(PaymentCallbackRequest request); }這里我把getChannel()放進(jìn)接口里有兩個(gè)原因第一分發(fā)器需要一個(gè)渠道標(biāo)識(shí)來決定 Map 的 key。雖然 Spring 默認(rèn)會(huì)用 beanName 做 key但接口顯式聲明 getChannel() 可以保證策略實(shí)現(xiàn)類明確知道自己歸屬哪個(gè)渠道避免靠約定俗成。第二如果某個(gè)渠道的邏輯比較特殊未來需要一個(gè) bean 處理多個(gè) channel可以在這個(gè)設(shè)計(jì)上進(jìn)一步擴(kuò)展。當(dāng)然也有人不喜歡在接口里放一個(gè)只返回常量的方法覺得這是代碼味道。對(duì)于這種觀點(diǎn)我比較務(wù)實(shí)在這個(gè)場(chǎng)景里它帶來的明確性遠(yuǎn)大于理論上的抽象不純而且它讓新增策略類時(shí)開發(fā)者不得不把渠道 ID 寫出來——這是一個(gè)強(qiáng)制約束反而能避免遺漏。3.2 實(shí)現(xiàn)三個(gè)策略類每個(gè)分支對(duì)應(yīng)一個(gè) Bean圍繞接口開發(fā)支付寶、微信、銀聯(lián)三個(gè)實(shí)現(xiàn)類。這里以支付寶為例注意它是獨(dú)立的 Spring Bean內(nèi)部使用構(gòu)造函數(shù)注入自己依賴的其他服務(wù)Component public class AlipayCallbackHandler implements CallbackHandler { private final OrderService orderService; private final AlipayBiz alipayBiz; public AlipayCallbackHandler(OrderService orderService, AlipayBiz alipayBiz) { this.orderService orderService; this.alipayBiz alipayBiz; } Override public String getChannel() { return alipay; } Override public CallbackResult process(PaymentCallbackRequest request) { if (!alipayBiz.verifySign(request.getParams())) { throw new BizException(支付寶驗(yàn)簽失敗); } String orderNo alipayBiz.getOrderNo(request.getParams()); Order order orderService.getByOrderNo(orderNo); // 訂單狀態(tài)更新、賬務(wù)處理、通知發(fā)送... return CallbackResult.success(); } }微信、銀聯(lián)的實(shí)現(xiàn)類結(jié)構(gòu)完全一致只是內(nèi)部調(diào)用各自的 SDK 和業(yè)務(wù)方法。注意關(guān)鍵點(diǎn)每個(gè)實(shí)現(xiàn)類的類名、Bean 名是什么都不重要重要的是 getChannel() 返回的字符串。這就是后面從 Map 里取策略的 key。3.3 分發(fā)器從 Map 里取出對(duì)應(yīng)策略分發(fā)器是整個(gè)模式里最薄、最核心的一層。它只做一件事根據(jù) channel 從 Map 里找到對(duì)應(yīng)的 handler 并調(diào)用。Component public class CallbackDispatcher { private final MapString, CallbackHandler handlerMap; public CallbackDispatcher(MapString, CallbackHandler handlerMap) { this.handlerMap handlerMap; } public CallbackResult dispatch(String channel, PaymentCallbackRequest request) { CallbackHandler handler handlerMap.get(channel); if (handler null) { throw new BizException(不支持的支付渠道: channel); } return handler.process(request); } }這里有個(gè)小細(xì)節(jié)值得說道說道handler 為 null 時(shí)不應(yīng)該讓空指針異常從業(yè)務(wù)代碼里拋出來而是主動(dòng)拋出帶渠道名的業(yè)務(wù)異常。這是排查線上問題時(shí)最省時(shí)間的做法——你不會(huì)看到一條籠統(tǒng)的 NPE而是直接看到不支持的支付渠道: unknown_channel一眼定位是前端傳錯(cuò)參數(shù)還是新渠道沒注冊(cè)。改造后原來的 Controller 調(diào)用從 200 行壓縮成兩行PostMapping(/callback/{channel}) public CallbackResult handleCallback(PathVariable String channel, RequestBody PaymentCallbackRequest request) { return dispatcher.dispatch(channel, request); }如果你擔(dān)心getChannel()與 Map key 不一致導(dǎo)致取不到 handler也可以在Configuration配置類里手動(dòng)注冊(cè)一個(gè)基于getChannel()返回值的 Map。不過對(duì)于大多數(shù)場(chǎng)景我建議直接用 Spring 自動(dòng)收集的 Map然后在getChannel()里返回和 key 一致的值就行因?yàn)檫@樣的代碼最精簡(jiǎn)。3.4 新舊代碼對(duì)比這套方案的價(jià)值到底在哪重構(gòu)完成之后把新舊代碼擺在一起看差異是非常直觀的維度改造前改造后新增一個(gè)渠道修改核心分發(fā)方法追加分支新增一個(gè)實(shí)現(xiàn)類加 Component修改某個(gè)渠道邏輯在長(zhǎng)方法里找到對(duì)應(yīng)分支直接打開對(duì)應(yīng)策略類修改單元測(cè)試需覆蓋整個(gè)分發(fā)方法單獨(dú)測(cè)一個(gè)策略類即可回歸風(fēng)險(xiǎn)改動(dòng)可能在中心位置影響所有分支策略之間完全隔離理解成本200 行無分節(jié)一個(gè)薄分發(fā)器 多個(gè)瘦實(shí)現(xiàn)類這意味著重構(gòu)之后我接第四個(gè)渠道的工作量從在別人代碼里小心翼翼找位置變成了新建一個(gè)類寫完業(yè)務(wù)邏輯重啟完事。調(diào)用方代碼零改動(dòng)也不需要在配置中心或什么地方聲明什么。這個(gè)體驗(yàn)差異真的只有踩過 if-else 泥潭的人才懂。4. 進(jìn)階玩法用自定義注解把渠道標(biāo)識(shí)從方法里挪到注解上4.1 getChannel() 的局限當(dāng)策略數(shù)量膨脹以后的維護(hù)壓力策略接口里的getChannel()方法解決了渠道標(biāo)識(shí)從哪來的問題但有一個(gè)小毛病每加一個(gè)策略都要重寫一遍返回渠道名的樣板代碼。更麻煩的是如果未來一個(gè)實(shí)現(xiàn)類要負(fù)責(zé)多個(gè)渠道比如國(guó)內(nèi)渠道和海外渠道都走同一套邏輯但標(biāo)識(shí)不同getChannel()只能返回一個(gè)值就不夠靈活了。這時(shí)可以進(jìn)入進(jìn)階方案把渠道標(biāo)識(shí)從方法簽名里挪到注解上用元信息描述這個(gè) Bean 是哪個(gè)渠道的策略。4.2 自定義一個(gè) StrategyChannel 注解注解本身很簡(jiǎn)單就是一個(gè)帶value()屬性的標(biāo)記注解Target(ElementType.TYPE) Retention(RetentionPolicy.RUNTIME) Component public interface StrategyChannel { String value(); }把Component也放進(jìn)注解定義里這樣實(shí)現(xiàn)類只需要標(biāo)一個(gè)StrategyChannel(alipay)同時(shí)完成了注冊(cè)為 Bean和聲明渠道標(biāo)識(shí)兩件事少敲一個(gè)注解。使用方式StrategyChannel(alipay) public class AlipayCallbackHandler implements CallbackHandler { Override public CallbackResult process(PaymentCallbackRequest request) { // 直接是業(yè)務(wù)邏輯不需要 getChannel() 樣板方法 } }4.3 通過 BeanPostProcessor 自動(dòng)收集并注冊(cè)有注解之后就需要一種機(jī)制把這些注解信息收集起來組成注冊(cè)中心。在 Spring 里最合適的切入點(diǎn)是BeanPostProcessor——在每個(gè) Bean 初始化完成后檢查它是否帶了StrategyChannel注解如果是就把它放進(jìn)注冊(cè)表。這里我定義一個(gè)輕量的注冊(cè)中心Component public class StrategyRegistry { private final MapString, CallbackHandler registry new ConcurrentHashMap(); public void register(String channel, CallbackHandler handler) { registry.put(channel, handler); } public CallbackHandler get(String channel) { return registry.get(channel); } }然后寫一個(gè)BeanPostProcessor在postProcessAfterInitialization階段掃描注解Component public class StrategyChannelProcessor implements BeanPostProcessor { private final StrategyRegistry registry; public StrategyChannelProcessor(StrategyRegistry registry) { this.registry registry; } Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { Class? beanClass AopProxyUtils.ultimateTargetClass(bean); StrategyChannel annotation AnnotationUtils.findAnnotation(beanClass, StrategyChannel.class); if (annotation ! null bean instanceof CallbackHandler handler) { registry.register(annotation.value(), handler); } return bean; } }注意我在代碼里故意用了AopProxyUtils.ultimateTargetClass(bean)而不是直接bean.getClass()。原因很實(shí)際如果這個(gè)策略 Bean 上掛了事務(wù)注解或者別的 AOP 切面Spring 注入進(jìn)來的實(shí)際上是一個(gè) JDK 動(dòng)態(tài)代理對(duì)象bean.getClass()拿到的是$Proxy類findAnnotation會(huì)掃不到原始類上的注解。用AopProxyUtils.ultimateTargetClass拿到的是被代理的最終目標(biāo)類注解信息才不會(huì)丟失。這個(gè)坑我見過好幾個(gè)同事踩過這里提前幫你踩平。調(diào)用方從原來的handlerMap.get(channel)變成registry.get(channel)邏輯幾乎不變。4.4 到底什么時(shí)候值得用注解方案不過在這里我要講點(diǎn)實(shí)在話如果你的渠道策略只有三五個(gè)用前置的基礎(chǔ)版 Map 注入就足夠了沒必要引入注解 BeanPostProcessor。理由有兩條代碼可讀性成本是真實(shí)存在的。BeanPostProcessor 這種全局鉤子比普通的 Map 注入難理解得多新同事看一眼為什么這個(gè)策略會(huì)自動(dòng)注冊(cè)進(jìn) registry需要先搞清楚 Spring 的生命周期機(jī)制。自動(dòng)收集越隱式排錯(cuò)越難。出了問題時(shí)注解掃描的鏈路比顯式getChannel()長(zhǎng)得多一般人排查起來會(huì)更吃力。那注解方案應(yīng)該用在什么時(shí)候我總結(jié)三個(gè)場(chǎng)景策略數(shù)量超過十個(gè)一個(gè)實(shí)現(xiàn)類需要綁定多個(gè)渠道標(biāo)識(shí)或者團(tuán)隊(duì)里約定了一些標(biāo)記性注解比如內(nèi)部框架的組件注解。在這些情況下注解 注冊(cè)中心帶來的整潔度才明顯超過它引入的復(fù)雜度。5. 實(shí)測(cè)中的坑與細(xì)節(jié)Map 注入、循環(huán)依賴、空策略這些攔路虎5.1 Map 的 key 到底是誰Bean 名覆蓋還是自定義這是策略 Spring 自動(dòng)裝配方案里最高頻的問題沒有之一。前面已經(jīng)說過Spring 自動(dòng)注入的MapString, CallbackHandler默認(rèn) key 是 Bean 名。這意味著如果你的實(shí)現(xiàn)類叫AlipayCallbackHandler那么 key 是alipayCallbackHandler不是alipay。你的業(yè)務(wù)請(qǐng)求里傳的 channel 是alipay如果直接用map.get(alipay)就會(huì)拿到 null然后一臉懵。解決方式有三種我按推薦程度排序方式一顯式指定 Bean 名讓 Bean 名和渠道名保持一致。Component(alipay) public class AlipayCallbackHandler implements CallbackHandler {這樣 Map 的 key 自然就是alipay。但這種寫法有一個(gè)隱患渠道標(biāo)識(shí)被放到了類名之外的字符串里如果渠道標(biāo)識(shí)改了Bean 名也要同步改否則失配。方式二繼承ApplicationContext后手動(dòng)處理。不推薦代碼太長(zhǎng)沒必要。方式三不依賴默認(rèn)的 Map 注入在Configuration配置類里手動(dòng)構(gòu)建一個(gè)以getChannel()為 key 的 MapBean public MapString, CallbackHandler callbackHandlerMap(ListCallbackHandler handlers) { return handlers.stream() .collect(Collectors.toMap(CallbackHandler::getChannel, Function.identity())); }這個(gè)方案我比較推薦把 List 注入進(jìn)來然后靠策略類自己聲明的getChannel()組裝成 Map。這樣 key 的語義是業(yè)務(wù)渠道標(biāo)識(shí)而不是Spring Bean 名語義準(zhǔn)確也不容易被重構(gòu)影響。不過要留意Collectors.toMap在 key 重復(fù)時(shí)會(huì)拋異常如果兩個(gè)不同實(shí)現(xiàn)類返回了同一個(gè)getChannel()應(yīng)用啟動(dòng)直接報(bào)IllegalStateException: Duplicate key。這其實(shí)是好事把問題在啟動(dòng)階段暴露出來而不是默默覆蓋。如果真有同一渠道多策略按條件選擇這種需求用toMap合并函數(shù)處理即可。5.2 策略 Bean 之間互相依賴引發(fā)的循環(huán)依賴問題我實(shí)際遇到過一次某個(gè)渠道的策略類里需要調(diào)用另一個(gè)策略類的公共方法比如公共的訂單狀態(tài)校驗(yàn)于是直接在策略 A 的構(gòu)造函數(shù)里注入了策略 B。結(jié)果 Spring Boot 啟動(dòng)直接報(bào)錯(cuò)Description: The dependencies of some of the beans in the application context form a cycleSpring Boot 2.6 開始默認(rèn)禁止循環(huán)依賴兩個(gè)策略類互相依賴或者分發(fā)器與策略類互相依賴都會(huì)在啟動(dòng)時(shí)被檢測(cè)出來。解決這個(gè)問題我建議從設(shè)計(jì)上打破循環(huán)策略類不應(yīng)該依賴另一個(gè)具體策略類而應(yīng)該把公共邏輯抽取到獨(dú)立的 Service 組件里然后兩個(gè)策略都去依賴那個(gè) Service。如果確實(shí)改不了最后的兜底辦法是配置spring: main: allow-circular-references: true這個(gè)開關(guān)我強(qiáng)烈不建議打開。它會(huì)讓你陷入啟動(dòng)時(shí)沒問題、運(yùn)行時(shí)代理異常的更深的坑。循環(huán)依賴的本質(zhì)是設(shè)計(jì)問題用策略模式本來就是為了解耦如果解耦之后反而出現(xiàn)互相依賴那一定是職責(zé)劃分還不到位需要回頭再看看接口方法設(shè)計(jì)。5.3 List 注入的順序如何實(shí)現(xiàn)多策略按優(yōu)先級(jí)嘗試前面講的是一渠道一策略的場(chǎng)景。但現(xiàn)實(shí)中還有一種更微妙的場(chǎng)景同一類業(yè)務(wù)有多個(gè)策略都聲稱自己可以處理只不過有優(yōu)先級(jí)關(guān)系希望從最高優(yōu)先級(jí)開始試直到有一個(gè)成功。這時(shí)策略接口就不能只暴露處理方法還需要暴露是否支持本次請(qǐng)求的判斷。而注入方式要從 Map 改成 Listpublic interface DispatchHandler { boolean support(Order order); DispatchResult handle(Order order); }多個(gè)實(shí)現(xiàn)類天然存在優(yōu)先級(jí)先后Spring 在注入 List 時(shí)是支持排序的只要實(shí)現(xiàn)類上標(biāo)注Order(1) Component public class VipOrderHandler implements DispatchHandler { ... } Order(2) Component public class NormalOrderHandler implements DispatchHandler { ... }Spring 收集 List 時(shí)會(huì)根據(jù)Order的值從小到大排列然后分發(fā)器依次遍歷、找到第一個(gè)support為 true 的處理器執(zhí)行即可。這種寫法在責(zé)任鏈和策略組的場(chǎng)景里非常好用但注意它和 Map 按渠道取策略 解決的問題不一樣不要混用。5.4 空策略兜底別讓 NPE 成為業(yè)務(wù)兜底邏輯策略 Map 的get方法天然存在返回 null 的可能。渠道標(biāo)識(shí)拼寫錯(cuò)誤、請(qǐng)求參數(shù)大小寫不一致、某個(gè)新渠道策略還沒開發(fā)完成但是前端已經(jīng)在調(diào)用——都會(huì)觸發(fā) null。我見過有的代碼直接handlerMap.get(channel).process(request);一旦get返回 null 就是 NPE線上排查還不一定能立刻想到是渠道未注冊(cè)。更好的是分發(fā)器里統(tǒng)一處理并拋出帶上下文信息的業(yè)務(wù)異常public CallbackResult dispatch(String channel, CallbackRequest request) { CallbackHandler handler handlerMap.get(channel); if (handler null) { throw new BizException(No handler for channel channel , available handlerMap.keySet()); } return handler.process(request); }把handlerMap.keySet()拼進(jìn)異常信息是我的個(gè)人習(xí)慣。線上一旦報(bào)錯(cuò)日志里直接把所有已注冊(cè)的渠道也打出來了你一眼就能看出到底是沒注冊(cè)還是請(qǐng)求參數(shù)錯(cuò)誤。這個(gè)小細(xì)節(jié)在排障時(shí)價(jià)值非常大。5.5 策略類的狀態(tài)管理Bean 是單例別在成員變量里緩存業(yè)務(wù)數(shù)據(jù)Spring 默認(rèn)的 Bean 作用域是單例也就是說所有請(qǐng)求共享同一個(gè)策略實(shí)例。這是一個(gè)很多人忽略的細(xì)節(jié)。如果你在策略實(shí)現(xiàn)類里寫了Component public class AlipayCallbackHandler implements CallbackHandler { private String currentOrderNo; // 錯(cuò)誤示例并發(fā)請(qǐng)求會(huì)互相覆蓋 }那恭喜你上線第二天你就會(huì)收獲一堆訂單狀態(tài)莫名錯(cuò)亂的工單。策略類必須是無狀態(tài)的它可以通過注入依賴使用別人的服務(wù)但絕不能在自己的字段里緩存任何與具體請(qǐng)求相關(guān)的數(shù)據(jù)。所有請(qǐng)求上下文都應(yīng)該通過方法參數(shù)傳遞。這是使用單例 Bean 的基本素養(yǎng)在策略模式里尤其要強(qiáng)調(diào)因?yàn)椴呗越涌诘姆椒ㄍ鶇?shù)比較少、處理流程復(fù)雜很考驗(yàn)自律。6. 策略模式的適用邊界別為了消 if-else 而消 if-else6.1 哪些分支根本不需要改造講完怎么做我必須講講什么時(shí)候不做。策略模式不是萬能良藥有些 if-else 是合理存在的不該為了優(yōu)雅而強(qiáng)行優(yōu)化。分支簡(jiǎn)單且固定比如性別判斷、狀態(tài)枚舉映射這類只有兩三個(gè)分支、幾乎沒有擴(kuò)展可能、每個(gè)分支只有一兩行代碼的情況下用策略模式純屬過度設(shè)計(jì)。你建接口、寫實(shí)現(xiàn)類、寫分發(fā)器的工作量比 if-else 本身還大團(tuán)隊(duì)維護(hù)成本反而更高。分支條件不互斥一個(gè)請(qǐng)求可能同時(shí)觸發(fā)多個(gè)邏輯分支比如既需要發(fā)短信又要發(fā)郵件這種情況下要的不是策略模式的多選一而是責(zé)任鏈或事件機(jī)制的多都執(zhí)行。如果你硬套策略模式反而會(huì)把邏輯搞得更加擰巴。策略之間有共享的上下文狀態(tài)策略模式希望策略是替換式的、無狀態(tài)的但如果每個(gè)分支需要共享一個(gè)復(fù)雜的調(diào)用鏈狀態(tài)比如長(zhǎng)時(shí)間會(huì)話、分步操作那策略模式并不合適你應(yīng)該考慮狀態(tài)模式或臨時(shí)存儲(chǔ)。6.2 除了策略類還有哪些消滅 if-else的姿勢(shì)在 Java 8 時(shí)代很多簡(jiǎn)單的分支處理可以用更輕量的手段枚舉策略模式。如果一個(gè)業(yè)務(wù)的策略實(shí)現(xiàn)邏輯比較短且類型固定直接在枚舉里定義行為是最緊湊的寫法public enum PayChannel { ALIPAY { Override public void pay(Order order) { // 支付寶支付邏輯 } }, WECHAT { Override public void pay(Order order) { // 微信支付邏輯 } }; public abstract void pay(Order order); }這種方法在分支邏輯簡(jiǎn)單、不需要依賴外部服務(wù)、類型固定時(shí)非常干凈。但如果策略實(shí)現(xiàn)需要注入其他 Service比如 orderService枚舉里要想辦法傳入依賴設(shè)計(jì)上會(huì)稍微繁瑣這時(shí)反而不如 Spring Bean 策略類順手。Map Function。Java 8 之后接口不一定用傳統(tǒng)的策略接口也可以直接用Function或者Consumer作為值MapString, FunctionOrder, Result actionMap new HashMap(); actionMap.put(alipay, order - payByAlipay(order)); actionMap.put(wechat, order - payByWechat(order));適合輕量、單方法的場(chǎng)景。缺點(diǎn)是可擴(kuò)展性弱多個(gè)方法時(shí) Function 表達(dá)不了業(yè)務(wù)邏輯復(fù)雜了還得回到顯式接口。規(guī)則引擎。當(dāng)分支條件不再是簡(jiǎn)單的channel.equals(...)而是多維度組合、幾十上百條規(guī)則時(shí)策略模式也會(huì)力不從心。規(guī)則引擎Drools、Easy Rules 之類可以把條件和動(dòng)作解耦得更徹底但引入成本高一般項(xiàng)目到不了這個(gè)量級(jí)不要輕易用。6.3 我的選型原則決策樹綜合多年實(shí)踐我在決定要不要用策略模式時(shí)腦子里其實(shí)是一個(gè)簡(jiǎn)單的決策樹分支數(shù)量超過 4 個(gè)且未來有明確的增長(zhǎng)預(yù)期——是考慮策略模式。分支邏輯是否超過 10 行——是值得拆如果每個(gè)分支只有一兩行先忍住。分支是否是互斥選擇而非都要執(zhí)行——是適用策略模式不是考慮責(zé)任鏈。各分支之間是否共享復(fù)雜的上下文狀態(tài)——是慎用策略模式。團(tuán)隊(duì)內(nèi)是否都熟悉 Spring 集合注入——如果只有你懂你寫的代碼再好三個(gè)月后沒人敢動(dòng)也是隱患。這套決策邏輯幫我避免了很多次為了炫技而踩坑的沖動(dòng)。技術(shù)選型永遠(yuǎn)不是哪種模式最優(yōu)雅而是哪種模式在團(tuán)隊(duì)的長(zhǎng)期維護(hù)成本里最劃算。寫到最后的一點(diǎn)點(diǎn)個(gè)人經(jīng)驗(yàn)這次重構(gòu)做完之后我最大的感受是策略模式 Spring 自動(dòng)裝配這套組合真正的價(jià)值不是消除了 if-else 這個(gè)表面結(jié)果而是改變了代碼的增長(zhǎng)方式。以前每加一個(gè)渠道是在給一個(gè)已經(jīng)有 200 行的老房子加一層地板現(xiàn)在每加一個(gè)渠道是給一棵樹添一根獨(dú)立的樹枝。新增代碼不需要擔(dān)心碰壞舊邏輯測(cè)試時(shí)也只需要盯著新策略類本身。如果你準(zhǔn)備動(dòng)手重構(gòu)類似的代碼我的建議是先別急著寫代碼花十分鐘把現(xiàn)有 if-else 的每個(gè)分支列出來找出穩(wěn)定的流程骨架和變化點(diǎn)把接口方法設(shè)計(jì)想清楚再動(dòng)手。接口設(shè)計(jì)對(duì)了后面所有實(shí)現(xiàn)類都是水到渠成的事接口設(shè)計(jì)錯(cuò)了后面會(huì)有更多的 if-else 等著你。祝你好運(yùn)希望下次代碼評(píng)審時(shí)你也敢自信地說這個(gè)方法已經(jīng)不需要再改了。 策略模式+Spring自動(dòng)裝配：重構(gòu)支付回調(diào)if-else的完整實(shí)踐
不知道你有沒有接過那種看起來很簡(jiǎn)單一打開就想關(guān)掉的老接口。我最近重構(gòu)一個(gè)支付回調(diào)服務(wù)里面那個(gè)分發(fā)方法一共 200 多行七八個(gè)if (channel.equals(...))分支挨個(gè)堆積每個(gè)分支里還各自牽扯對(duì)賬、狀態(tài)更新、消息推送。每次新對(duì)接一個(gè)渠道我都要在別人寫了幾年的代碼里找到那個(gè)方法小心翼翼地把新分支塞進(jìn)去生怕動(dòng)錯(cuò)一個(gè)括號(hào)。改完之后代碼評(píng)審時(shí)同事問了一句這方法怎么又變長(zhǎng)了我一時(shí)語塞就是因?yàn)檫@句話我下決心把這塊改造成策略模式 Spring 自動(dòng)裝配的方案。這篇文章就完整記錄我從為什么要改、怎么設(shè)計(jì)到實(shí)際重構(gòu)、踩坑收尾的全過程給同樣被 if-else 支配的朋友一條可以直接照抄的路線。1. 被 if-else 支配的回調(diào)分發(fā)先看清痛點(diǎn)到底在哪1.1 一段典型的分支堆砌代碼長(zhǎng)什么樣業(yè)務(wù)背景很樸素系統(tǒng)需要接收不同第三方支付渠道的回調(diào)有支付寶、微信、銀聯(lián)后續(xù)還要接京東、抖音支付。每個(gè)渠道的回調(diào)報(bào)文格式不一樣、驗(yàn)簽邏輯不一樣、入賬處理也不一樣。最初版本只支持支付寶后來微信接入直接在原方法上追加else if再后來銀聯(lián)也接入繼續(xù)追加。等我要接第四個(gè)渠道時(shí)代碼已經(jīng)長(zhǎng)成這樣public CallbackResult handleCallback(String channel, CallbackRequest request) { if (alipay.equals(channel)) { AlipayBiz alipayBiz new AlipayBiz(); if (!alipayBiz.verifySign(request.getParams())) { throw new BizException(支付寶驗(yàn)簽失敗); } String orderNo alipayBiz.getOrderNo(request.getParams()); Order order orderService.getByOrderNo(orderNo); // 更新訂單狀態(tài)、處理商品邏輯、發(fā)送站內(nèi)通知... // 中間還有幾十行業(yè)務(wù)代碼 return CallbackResult.success(); } else if (wechat.equals(channel)) { WechatBiz wechatBiz new WechatBiz(); if (!wechatBiz.verifySign(request.getParams())) { throw new BizException(微信驗(yàn)簽失敗); } // 又是一大段幾乎沒有復(fù)用性的邏輯 return CallbackResult.success(); } else if (unionpay.equals(channel)) { // 第三個(gè)渠道邏輯繼續(xù)復(fù)制粘貼 } else { throw new BizException(不支持的渠道); } }這段代碼表面上是能用實(shí)際上四個(gè)問題一個(gè)比一個(gè)致命第一可讀性極差。200 行方法從頭到尾沒有分節(jié)核心業(yè)務(wù)邏輯完全淹沒在渠道判斷里。新同事接手時(shí)根本分不清哪些代碼是公共流程、哪些是渠道差異邏輯連定位一個(gè) bug 都要來回滾動(dòng)看半天。第二擴(kuò)展成本高。每加一個(gè)渠道就要改動(dòng)這個(gè)老方法而改一個(gè)每天都在線上跑的入口方法心理壓力是巨大的。代碼越加越長(zhǎng)回歸測(cè)試的范圍也越來越大因?yàn)楦膭?dòng)的位置太中心了誰都不敢保證動(dòng)一個(gè)分支會(huì)不會(huì)影響另一個(gè)分支。第三可測(cè)試性幾乎為零。想測(cè)試第四個(gè)渠道的邏輯得先跑完前三個(gè)分支的條件判斷。想單獨(dú)驗(yàn)證支付寶的驗(yàn)簽邏輯抱歉你得構(gòu)造整個(gè)handleCallback的調(diào)用鏈路連微信和銀聯(lián)的分支代碼也會(huì)被加載進(jìn)測(cè)試覆蓋率里。第四很難復(fù)用。如果未來有其他接口比如主動(dòng)查單、退款回調(diào)也要按渠道分發(fā)這段邏輯無法被復(fù)用只能再次復(fù)制一份然后繼續(xù)膨脹。這種代碼不是 爛代碼 那么簡(jiǎn)單它是一個(gè)會(huì)讓團(tuán)隊(duì)整體效率不斷下降的壞味道。而且我要強(qiáng)調(diào)用 switch-case 替換 if-else 解決不了本質(zhì)問題因?yàn)榉种袛嗪蜆I(yè)務(wù)邏輯仍然強(qiáng)耦合在一個(gè)方法里。哪怕寫成 switch每加一個(gè) case 仍然要?jiǎng)舆@個(gè)方法。1.2 為什么很多人知道策略模式卻照樣寫不好有人說策略模式嘛誰不會(huì)。但我在代碼評(píng)審里見過太多次偽策略模式——名義上建了策略接口實(shí)際干的事情并沒有解決問題。最常見的三種變形變形一策略類內(nèi)部繼續(xù) if-else。把所有渠道處理邏輯塞到一個(gè)大工廠類里工廠類的getHandler(channel)方法依然是 8 個(gè)條件判斷。這只是把 if-else 從方法里挪到了工廠里換湯不換藥。變形二手動(dòng)維護(hù)策略注冊(cè)表。知道要用 Map于是寫一個(gè)static MapString, Handler然后在每個(gè)實(shí)現(xiàn)類的靜態(tài)代碼塊里put(alipay, this)或者在一個(gè)集中配置類里手動(dòng) new 出來再 put。這樣搞的問題在于策略實(shí)例的生命周期完全靠自己管理Spring 的依賴注入、AOP、代理這些能力全都浪費(fèi)了而且很容易出現(xiàn)忘記注冊(cè)導(dǎo)致運(yùn)行時(shí) NPE。變形三用反射或字符串拼接去做動(dòng)態(tài)分發(fā)。比如根據(jù) channel 拼出類名然后Class.forName反射調(diào)用。這種方案看起來巧妙實(shí)際上把類型安全徹底丟掉了類名一重構(gòu)就全盤崩性能也受影響排查問題非常費(fèi)勁。真正正確的姿勢(shì)是什么就是利用 Spring 容器自己的自動(dòng)裝配能力把每個(gè)渠道的處理邏輯做成一個(gè)獨(dú)立的 Spring Bean然后讓 Spring 把同一接口下的所有實(shí)現(xiàn)類收集起來自動(dòng)組裝成一個(gè) Map。調(diào)用方一行代碼從 Map 里取出對(duì)應(yīng)策略甚至不需要關(guān)心到底有哪些策略實(shí)現(xiàn)類存在。這個(gè)思路的核心轉(zhuǎn)變是——選擇權(quán)從調(diào)用方代碼轉(zhuǎn)移到了IoC 容器。2. 策略模式在 Spring 里的正確打開方式核心是讓容器替你完成選擇2.1 經(jīng)典策略模式與 Spring 容器策略模式的差異先回憶一下經(jīng)典策略模式的教科書寫法有一個(gè)策略接口多個(gè)具體策略實(shí)現(xiàn)類然后一個(gè) Context 類持有策略接口引用客戶端在調(diào)用時(shí)手動(dòng)選擇具體策略傳入 Context。核心思想是把算法獨(dú)立封裝使它們可以互相替換。到了 Spring 項(xiàng)目里這個(gè)模式有一個(gè)天然的升級(jí)版具體策略實(shí)現(xiàn)類交給 Spring 管理成為 Bean然后通過集合注入把容器內(nèi)所有策略接口的實(shí)現(xiàn)類自動(dòng)收集起來。調(diào)用方不再選擇策略而是把選擇條件交給 Spring 裝配的結(jié)果——一個(gè)以渠道標(biāo)識(shí)為 key 的 Map。很多人第一次看到這種寫法時(shí)會(huì)覺得奇怪Map 也能注入這里要展開說說因?yàn)檫@是整個(gè)方案里的關(guān)鍵點(diǎn)也是很多人實(shí)際用錯(cuò)的環(huán)節(jié)。2.2 Map 注入與 List 注入Spring 集合注入能力的兩種用法Spring 允許在注入點(diǎn)直接聲明一個(gè)接口類型的集合比如Component public class PaymentDispatcher { private final MapString, CallbackHandler handlerMap; public PaymentDispatcher(MapString, CallbackHandler handlerMap) { this.handlerMap handlerMap; } }啟動(dòng)時(shí) Spring 會(huì)掃描容器中所有CallbackHandler接口的實(shí)現(xiàn)類 Bean把它們按照beanName 作為 key、實(shí)例作為 value的方式組裝成一個(gè)MapString, CallbackHandler注入進(jìn)來。如果用 Listprivate final ListCallbackHandler handlers;那就得到一個(gè)包含所有實(shí)現(xiàn)類的 List順序可以通過Order注解或?qū)崿F(xiàn)Ordered接口來控制。這里有兩個(gè)非常容易踩的細(xì)節(jié)第一個(gè)細(xì)節(jié)Map 的 key 默認(rèn)是 Bean 的名字不是實(shí)現(xiàn)類上的任何自定義標(biāo)識(shí)。如果你的實(shí)現(xiàn)類叫AlipayCallbackHandler那么默認(rèn) key 是alipayCallbackHandler首字母小寫而不是alipay。如果你調(diào)用時(shí)handlerMap.get(alipay)拿到的就是 null。這就是很多人第一次改造失敗的直接原因。第二個(gè)細(xì)節(jié)Map 注入不會(huì)觸發(fā)類型轉(zhuǎn)換或排序。Spring 會(huì)把所有匹配類型的 Bean 一次性收集進(jìn) Map如果你希望按特定的規(guī)則排列得自己在策略接口上設(shè)計(jì)優(yōu)先級(jí)的概念或者使用Order配合 List 使用。聊清楚這兩點(diǎn)之后你就可以看出來策略模式 Spring 自動(dòng)裝配的核心套路其實(shí)非常簡(jiǎn)潔定義策略接口接口方法就是業(yè)務(wù)處理的統(tǒng)一入口。每個(gè)分支邏輯寫成一個(gè)實(shí)現(xiàn)類注冊(cè)為 Spring Bean。用一個(gè)分發(fā)器Dispatcher / Holder注入策略 Map。調(diào)用方只依賴分發(fā)器傳入業(yè)務(wù)類型標(biāo)識(shí)拿到對(duì)應(yīng)策略實(shí)例。擴(kuò)展新渠道時(shí)只新增一個(gè)策略 Bean其他代碼完全不動(dòng)。這個(gè)套路比手動(dòng)寫工廠的優(yōu)雅之處在于注冊(cè)動(dòng)作由容器完成天然避免了忘了 put 的問題。Spring 容器本身就是最大的工廠你只要把實(shí)現(xiàn)類定義成 Bean它就自動(dòng)進(jìn)了 Map。2.3 為什么推薦構(gòu)造函數(shù)注入而不是字段注入在 Spring 策略集合注入的寫法里我強(qiáng)烈建議用構(gòu)造函數(shù)注入而且用final修飾字段。除了 Spring 官方推薦的不可變依賴原則之外在策略分發(fā)器這個(gè)特定場(chǎng)景里還有兩個(gè)實(shí)際收益防止空指針。如果一個(gè)環(huán)節(jié)你忘了聲明構(gòu)造參數(shù)Spring 啟動(dòng)時(shí)直接報(bào)錯(cuò)而不是運(yùn)行到某次調(diào)用時(shí)才發(fā)現(xiàn) handlerMap 是 null。方便單元測(cè)試。構(gòu)造函數(shù)注入意味著你可以直接new PaymentDispatcher(Map.of(alipay, mockHandler))來構(gòu)造測(cè)試對(duì)象不需要啟動(dòng) Spring 容器。我在項(xiàng)目里用 Lombok 的RequiredArgsConstructor配合final字段代碼非常干凈這也是目前 Spring Boot 項(xiàng)目里最主流的寫法。3. 重構(gòu)全過程從三大渠道 if-else 到策略分發(fā)器配完整代碼3.1 先定義策略接口想清楚變化的是什么回到支付回調(diào)的例子。重構(gòu)的第一步不是寫實(shí)現(xiàn)類而是想清楚一個(gè)問題這段代碼里什么東西是穩(wěn)定的什么東西是變化的穩(wěn)定的是整個(gè)回調(diào)處理的流程骨架——驗(yàn)簽、取訂單號(hào)、更新狀態(tài)、返回結(jié)果。 變化的是每個(gè)渠道的驗(yàn)簽方式、報(bào)文解析方式、可能還有一些不同的業(yè)務(wù)規(guī)則。策略接口就把變化的部分統(tǒng)一成一個(gè)方法簽名。在這個(gè)場(chǎng)景里我定義接口如下public interface CallbackHandler { String getChannel(); CallbackResult process(PaymentCallbackRequest request); }這里我把getChannel()放進(jìn)接口里有兩個(gè)原因第一分發(fā)器需要一個(gè)渠道標(biāo)識(shí)來決定 Map 的 key。雖然 Spring 默認(rèn)會(huì)用 beanName 做 key但接口顯式聲明 getChannel() 可以保證策略實(shí)現(xiàn)類明確知道自己歸屬哪個(gè)渠道避免靠約定俗成。第二如果某個(gè)渠道的邏輯比較特殊未來需要一個(gè) bean 處理多個(gè) channel可以在這個(gè)設(shè)計(jì)上進(jìn)一步擴(kuò)展。當(dāng)然也有人不喜歡在接口里放一個(gè)只返回常量的方法覺得這是代碼味道。對(duì)于這種觀點(diǎn)我比較務(wù)實(shí)在這個(gè)場(chǎng)景里它帶來的明確性遠(yuǎn)大于理論上的抽象不純而且它讓新增策略類時(shí)開發(fā)者不得不把渠道 ID 寫出來——這是一個(gè)強(qiáng)制約束反而能避免遺漏。3.2 實(shí)現(xiàn)三個(gè)策略類每個(gè)分支對(duì)應(yīng)一個(gè) Bean圍繞接口開發(fā)支付寶、微信、銀聯(lián)三個(gè)實(shí)現(xiàn)類。這里以支付寶為例注意它是獨(dú)立的 Spring Bean內(nèi)部使用構(gòu)造函數(shù)注入自己依賴的其他服務(wù)Component public class AlipayCallbackHandler implements CallbackHandler { private final OrderService orderService; private final AlipayBiz alipayBiz; public AlipayCallbackHandler(OrderService orderService, AlipayBiz alipayBiz) { this.orderService orderService; this.alipayBiz alipayBiz; } Override public String getChannel() { return alipay; } Override public CallbackResult process(PaymentCallbackRequest request) { if (!alipayBiz.verifySign(request.getParams())) { throw new BizException(支付寶驗(yàn)簽失敗); } String orderNo alipayBiz.getOrderNo(request.getParams()); Order order orderService.getByOrderNo(orderNo); // 訂單狀態(tài)更新、賬務(wù)處理、通知發(fā)送... return CallbackResult.success(); } }微信、銀聯(lián)的實(shí)現(xiàn)類結(jié)構(gòu)完全一致只是內(nèi)部調(diào)用各自的 SDK 和業(yè)務(wù)方法。注意關(guān)鍵點(diǎn)每個(gè)實(shí)現(xiàn)類的類名、Bean 名是什么都不重要重要的是 getChannel() 返回的字符串。這就是后面從 Map 里取策略的 key。3.3 分發(fā)器從 Map 里取出對(duì)應(yīng)策略分發(fā)器是整個(gè)模式里最薄、最核心的一層。它只做一件事根據(jù) channel 從 Map 里找到對(duì)應(yīng)的 handler 并調(diào)用。Component public class CallbackDispatcher { private final MapString, CallbackHandler handlerMap; public CallbackDispatcher(MapString, CallbackHandler handlerMap) { this.handlerMap handlerMap; } public CallbackResult dispatch(String channel, PaymentCallbackRequest request) { CallbackHandler handler handlerMap.get(channel); if (handler null) { throw new BizException(不支持的支付渠道: channel); } return handler.process(request); } }這里有個(gè)小細(xì)節(jié)值得說道說道handler 為 null 時(shí)不應(yīng)該讓空指針異常從業(yè)務(wù)代碼里拋出來而是主動(dòng)拋出帶渠道名的業(yè)務(wù)異常。這是排查線上問題時(shí)最省時(shí)間的做法——你不會(huì)看到一條籠統(tǒng)的 NPE而是直接看到不支持的支付渠道: unknown_channel一眼定位是前端傳錯(cuò)參數(shù)還是新渠道沒注冊(cè)。改造后原來的 Controller 調(diào)用從 200 行壓縮成兩行PostMapping(/callback/{channel}) public CallbackResult handleCallback(PathVariable String channel, RequestBody PaymentCallbackRequest request) { return dispatcher.dispatch(channel, request); }如果你擔(dān)心getChannel()與 Map key 不一致導(dǎo)致取不到 handler也可以在Configuration配置類里手動(dòng)注冊(cè)一個(gè)基于getChannel()返回值的 Map。不過對(duì)于大多數(shù)場(chǎng)景我建議直接用 Spring 自動(dòng)收集的 Map然后在getChannel()里返回和 key 一致的值就行因?yàn)檫@樣的代碼最精簡(jiǎn)。3.4 新舊代碼對(duì)比這套方案的價(jià)值到底在哪重構(gòu)完成之后把新舊代碼擺在一起看差異是非常直觀的維度改造前改造后新增一個(gè)渠道修改核心分發(fā)方法追加分支新增一個(gè)實(shí)現(xiàn)類加 Component修改某個(gè)渠道邏輯在長(zhǎng)方法里找到對(duì)應(yīng)分支直接打開對(duì)應(yīng)策略類修改單元測(cè)試需覆蓋整個(gè)分發(fā)方法單獨(dú)測(cè)一個(gè)策略類即可回歸風(fēng)險(xiǎn)改動(dòng)可能在中心位置影響所有分支策略之間完全隔離理解成本200 行無分節(jié)一個(gè)薄分發(fā)器 多個(gè)瘦實(shí)現(xiàn)類這意味著重構(gòu)之后我接第四個(gè)渠道的工作量從在別人代碼里小心翼翼找位置變成了新建一個(gè)類寫完業(yè)務(wù)邏輯重啟完事。調(diào)用方代碼零改動(dòng)也不需要在配置中心或什么地方聲明什么。這個(gè)體驗(yàn)差異真的只有踩過 if-else 泥潭的人才懂。4. 進(jìn)階玩法用自定義注解把渠道標(biāo)識(shí)從方法里挪到注解上4.1 getChannel() 的局限當(dāng)策略數(shù)量膨脹以后的維護(hù)壓力策略接口里的getChannel()方法解決了渠道標(biāo)識(shí)從哪來的問題但有一個(gè)小毛病每加一個(gè)策略都要重寫一遍返回渠道名的樣板代碼。更麻煩的是如果未來一個(gè)實(shí)現(xiàn)類要負(fù)責(zé)多個(gè)渠道比如國(guó)內(nèi)渠道和海外渠道都走同一套邏輯但標(biāo)識(shí)不同getChannel()只能返回一個(gè)值就不夠靈活了。這時(shí)可以進(jìn)入進(jìn)階方案把渠道標(biāo)識(shí)從方法簽名里挪到注解上用元信息描述這個(gè) Bean 是哪個(gè)渠道的策略。4.2 自定義一個(gè) StrategyChannel 注解注解本身很簡(jiǎn)單就是一個(gè)帶value()屬性的標(biāo)記注解Target(ElementType.TYPE) Retention(RetentionPolicy.RUNTIME) Component public interface StrategyChannel { String value(); }把Component也放進(jìn)注解定義里這樣實(shí)現(xiàn)類只需要標(biāo)一個(gè)StrategyChannel(alipay)同時(shí)完成了注冊(cè)為 Bean和聲明渠道標(biāo)識(shí)兩件事少敲一個(gè)注解。使用方式StrategyChannel(alipay) public class AlipayCallbackHandler implements CallbackHandler { Override public CallbackResult process(PaymentCallbackRequest request) { // 直接是業(yè)務(wù)邏輯不需要 getChannel() 樣板方法 } }4.3 通過 BeanPostProcessor 自動(dòng)收集并注冊(cè)有注解之后就需要一種機(jī)制把這些注解信息收集起來組成注冊(cè)中心。在 Spring 里最合適的切入點(diǎn)是BeanPostProcessor——在每個(gè) Bean 初始化完成后檢查它是否帶了StrategyChannel注解如果是就把它放進(jìn)注冊(cè)表。這里我定義一個(gè)輕量的注冊(cè)中心Component public class StrategyRegistry { private final MapString, CallbackHandler registry new ConcurrentHashMap(); public void register(String channel, CallbackHandler handler) { registry.put(channel, handler); } public CallbackHandler get(String channel) { return registry.get(channel); } }然后寫一個(gè)BeanPostProcessor在postProcessAfterInitialization階段掃描注解Component public class StrategyChannelProcessor implements BeanPostProcessor { private final StrategyRegistry registry; public StrategyChannelProcessor(StrategyRegistry registry) { this.registry registry; } Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { Class? beanClass AopProxyUtils.ultimateTargetClass(bean); StrategyChannel annotation AnnotationUtils.findAnnotation(beanClass, StrategyChannel.class); if (annotation ! null bean instanceof CallbackHandler handler) { registry.register(annotation.value(), handler); } return bean; } }注意我在代碼里故意用了AopProxyUtils.ultimateTargetClass(bean)而不是直接bean.getClass()。原因很實(shí)際如果這個(gè)策略 Bean 上掛了事務(wù)注解或者別的 AOP 切面Spring 注入進(jìn)來的實(shí)際上是一個(gè) JDK 動(dòng)態(tài)代理對(duì)象bean.getClass()拿到的是$Proxy類findAnnotation會(huì)掃不到原始類上的注解。用AopProxyUtils.ultimateTargetClass拿到的是被代理的最終目標(biāo)類注解信息才不會(huì)丟失。這個(gè)坑我見過好幾個(gè)同事踩過這里提前幫你踩平。調(diào)用方從原來的handlerMap.get(channel)變成registry.get(channel)邏輯幾乎不變。4.4 到底什么時(shí)候值得用注解方案不過在這里我要講點(diǎn)實(shí)在話如果你的渠道策略只有三五個(gè)用前置的基礎(chǔ)版 Map 注入就足夠了沒必要引入注解 BeanPostProcessor。理由有兩條代碼可讀性成本是真實(shí)存在的。BeanPostProcessor 這種全局鉤子比普通的 Map 注入難理解得多新同事看一眼為什么這個(gè)策略會(huì)自動(dòng)注冊(cè)進(jìn) registry需要先搞清楚 Spring 的生命周期機(jī)制。自動(dòng)收集越隱式排錯(cuò)越難。出了問題時(shí)注解掃描的鏈路比顯式getChannel()長(zhǎng)得多一般人排查起來會(huì)更吃力。那注解方案應(yīng)該用在什么時(shí)候我總結(jié)三個(gè)場(chǎng)景策略數(shù)量超過十個(gè)一個(gè)實(shí)現(xiàn)類需要綁定多個(gè)渠道標(biāo)識(shí)或者團(tuán)隊(duì)里約定了一些標(biāo)記性注解比如內(nèi)部框架的組件注解。在這些情況下注解 注冊(cè)中心帶來的整潔度才明顯超過它引入的復(fù)雜度。5. 實(shí)測(cè)中的坑與細(xì)節(jié)Map 注入、循環(huán)依賴、空策略這些攔路虎5.1 Map 的 key 到底是誰Bean 名覆蓋還是自定義這是策略 Spring 自動(dòng)裝配方案里最高頻的問題沒有之一。前面已經(jīng)說過Spring 自動(dòng)注入的MapString, CallbackHandler默認(rèn) key 是 Bean 名。這意味著如果你的實(shí)現(xiàn)類叫AlipayCallbackHandler那么 key 是alipayCallbackHandler不是alipay。你的業(yè)務(wù)請(qǐng)求里傳的 channel 是alipay如果直接用map.get(alipay)就會(huì)拿到 null然后一臉懵。解決方式有三種我按推薦程度排序方式一顯式指定 Bean 名讓 Bean 名和渠道名保持一致。Component(alipay) public class AlipayCallbackHandler implements CallbackHandler {這樣 Map 的 key 自然就是alipay。但這種寫法有一個(gè)隱患渠道標(biāo)識(shí)被放到了類名之外的字符串里如果渠道標(biāo)識(shí)改了Bean 名也要同步改否則失配。方式二繼承ApplicationContext后手動(dòng)處理。不推薦代碼太長(zhǎng)沒必要。方式三不依賴默認(rèn)的 Map 注入在Configuration配置類里手動(dòng)構(gòu)建一個(gè)以getChannel()為 key 的 MapBean public MapString, CallbackHandler callbackHandlerMap(ListCallbackHandler handlers) { return handlers.stream() .collect(Collectors.toMap(CallbackHandler::getChannel, Function.identity())); }這個(gè)方案我比較推薦把 List 注入進(jìn)來然后靠策略類自己聲明的getChannel()組裝成 Map。這樣 key 的語義是業(yè)務(wù)渠道標(biāo)識(shí)而不是Spring Bean 名語義準(zhǔn)確也不容易被重構(gòu)影響。不過要留意Collectors.toMap在 key 重復(fù)時(shí)會(huì)拋異常如果兩個(gè)不同實(shí)現(xiàn)類返回了同一個(gè)getChannel()應(yīng)用啟動(dòng)直接報(bào)IllegalStateException: Duplicate key。這其實(shí)是好事把問題在啟動(dòng)階段暴露出來而不是默默覆蓋。如果真有同一渠道多策略按條件選擇這種需求用toMap合并函數(shù)處理即可。5.2 策略 Bean 之間互相依賴引發(fā)的循環(huán)依賴問題我實(shí)際遇到過一次某個(gè)渠道的策略類里需要調(diào)用另一個(gè)策略類的公共方法比如公共的訂單狀態(tài)校驗(yàn)于是直接在策略 A 的構(gòu)造函數(shù)里注入了策略 B。結(jié)果 Spring Boot 啟動(dòng)直接報(bào)錯(cuò)Description: The dependencies of some of the beans in the application context form a cycleSpring Boot 2.6 開始默認(rèn)禁止循環(huán)依賴兩個(gè)策略類互相依賴或者分發(fā)器與策略類互相依賴都會(huì)在啟動(dòng)時(shí)被檢測(cè)出來。解決這個(gè)問題我建議從設(shè)計(jì)上打破循環(huán)策略類不應(yīng)該依賴另一個(gè)具體策略類而應(yīng)該把公共邏輯抽取到獨(dú)立的 Service 組件里然后兩個(gè)策略都去依賴那個(gè) Service。如果確實(shí)改不了最后的兜底辦法是配置spring: main: allow-circular-references: true這個(gè)開關(guān)我強(qiáng)烈不建議打開。它會(huì)讓你陷入啟動(dòng)時(shí)沒問題、運(yùn)行時(shí)代理異常的更深的坑。循環(huán)依賴的本質(zhì)是設(shè)計(jì)問題用策略模式本來就是為了解耦如果解耦之后反而出現(xiàn)互相依賴那一定是職責(zé)劃分還不到位需要回頭再看看接口方法設(shè)計(jì)。5.3 List 注入的順序如何實(shí)現(xiàn)多策略按優(yōu)先級(jí)嘗試前面講的是一渠道一策略的場(chǎng)景。但現(xiàn)實(shí)中還有一種更微妙的場(chǎng)景同一類業(yè)務(wù)有多個(gè)策略都聲稱自己可以處理只不過有優(yōu)先級(jí)關(guān)系希望從最高優(yōu)先級(jí)開始試直到有一個(gè)成功。這時(shí)策略接口就不能只暴露處理方法還需要暴露是否支持本次請(qǐng)求的判斷。而注入方式要從 Map 改成 Listpublic interface DispatchHandler { boolean support(Order order); DispatchResult handle(Order order); }多個(gè)實(shí)現(xiàn)類天然存在優(yōu)先級(jí)先后Spring 在注入 List 時(shí)是支持排序的只要實(shí)現(xiàn)類上標(biāo)注Order(1) Component public class VipOrderHandler implements DispatchHandler { ... } Order(2) Component public class NormalOrderHandler implements DispatchHandler { ... }Spring 收集 List 時(shí)會(huì)根據(jù)Order的值從小到大排列然后分發(fā)器依次遍歷、找到第一個(gè)support為 true 的處理器執(zhí)行即可。這種寫法在責(zé)任鏈和策略組的場(chǎng)景里非常好用但注意它和 Map 按渠道取策略 解決的問題不一樣不要混用。5.4 空策略兜底別讓 NPE 成為業(yè)務(wù)兜底邏輯策略 Map 的get方法天然存在返回 null 的可能。渠道標(biāo)識(shí)拼寫錯(cuò)誤、請(qǐng)求參數(shù)大小寫不一致、某個(gè)新渠道策略還沒開發(fā)完成但是前端已經(jīng)在調(diào)用——都會(huì)觸發(fā) null。我見過有的代碼直接handlerMap.get(channel).process(request);一旦get返回 null 就是 NPE線上排查還不一定能立刻想到是渠道未注冊(cè)。更好的是分發(fā)器里統(tǒng)一處理并拋出帶上下文信息的業(yè)務(wù)異常public CallbackResult dispatch(String channel, CallbackRequest request) { CallbackHandler handler handlerMap.get(channel); if (handler null) { throw new BizException(No handler for channel channel , available handlerMap.keySet()); } return handler.process(request); }把handlerMap.keySet()拼進(jìn)異常信息是我的個(gè)人習(xí)慣。線上一旦報(bào)錯(cuò)日志里直接把所有已注冊(cè)的渠道也打出來了你一眼就能看出到底是沒注冊(cè)還是請(qǐng)求參數(shù)錯(cuò)誤。這個(gè)小細(xì)節(jié)在排障時(shí)價(jià)值非常大。5.5 策略類的狀態(tài)管理Bean 是單例別在成員變量里緩存業(yè)務(wù)數(shù)據(jù)Spring 默認(rèn)的 Bean 作用域是單例也就是說所有請(qǐng)求共享同一個(gè)策略實(shí)例。這是一個(gè)很多人忽略的細(xì)節(jié)。如果你在策略實(shí)現(xiàn)類里寫了Component public class AlipayCallbackHandler implements CallbackHandler { private String currentOrderNo; // 錯(cuò)誤示例并發(fā)請(qǐng)求會(huì)互相覆蓋 }那恭喜你上線第二天你就會(huì)收獲一堆訂單狀態(tài)莫名錯(cuò)亂的工單。策略類必須是無狀態(tài)的它可以通過注入依賴使用別人的服務(wù)但絕不能在自己的字段里緩存任何與具體請(qǐng)求相關(guān)的數(shù)據(jù)。所有請(qǐng)求上下文都應(yīng)該通過方法參數(shù)傳遞。這是使用單例 Bean 的基本素養(yǎng)在策略模式里尤其要強(qiáng)調(diào)因?yàn)椴呗越涌诘姆椒ㄍ鶇?shù)比較少、處理流程復(fù)雜很考驗(yàn)自律。6. 策略模式的適用邊界別為了消 if-else 而消 if-else6.1 哪些分支根本不需要改造講完怎么做我必須講講什么時(shí)候不做。策略模式不是萬能良藥有些 if-else 是合理存在的不該為了優(yōu)雅而強(qiáng)行優(yōu)化。分支簡(jiǎn)單且固定比如性別判斷、狀態(tài)枚舉映射這類只有兩三個(gè)分支、幾乎沒有擴(kuò)展可能、每個(gè)分支只有一兩行代碼的情況下用策略模式純屬過度設(shè)計(jì)。你建接口、寫實(shí)現(xiàn)類、寫分發(fā)器的工作量比 if-else 本身還大團(tuán)隊(duì)維護(hù)成本反而更高。分支條件不互斥一個(gè)請(qǐng)求可能同時(shí)觸發(fā)多個(gè)邏輯分支比如既需要發(fā)短信又要發(fā)郵件這種情況下要的不是策略模式的多選一而是責(zé)任鏈或事件機(jī)制的多都執(zhí)行。如果你硬套策略模式反而會(huì)把邏輯搞得更加擰巴。策略之間有共享的上下文狀態(tài)策略模式希望策略是替換式的、無狀態(tài)的但如果每個(gè)分支需要共享一個(gè)復(fù)雜的調(diào)用鏈狀態(tài)比如長(zhǎng)時(shí)間會(huì)話、分步操作那策略模式并不合適你應(yīng)該考慮狀態(tài)模式或臨時(shí)存儲(chǔ)。6.2 除了策略類還有哪些消滅 if-else的姿勢(shì)在 Java 8 時(shí)代很多簡(jiǎn)單的分支處理可以用更輕量的手段枚舉策略模式。如果一個(gè)業(yè)務(wù)的策略實(shí)現(xiàn)邏輯比較短且類型固定直接在枚舉里定義行為是最緊湊的寫法public enum PayChannel { ALIPAY { Override public void pay(Order order) { // 支付寶支付邏輯 } }, WECHAT { Override public void pay(Order order) { // 微信支付邏輯 } }; public abstract void pay(Order order); }這種方法在分支邏輯簡(jiǎn)單、不需要依賴外部服務(wù)、類型固定時(shí)非常干凈。但如果策略實(shí)現(xiàn)需要注入其他 Service比如 orderService枚舉里要想辦法傳入依賴設(shè)計(jì)上會(huì)稍微繁瑣這時(shí)反而不如 Spring Bean 策略類順手。Map Function。Java 8 之后接口不一定用傳統(tǒng)的策略接口也可以直接用Function或者Consumer作為值MapString, FunctionOrder, Result actionMap new HashMap(); actionMap.put(alipay, order - payByAlipay(order)); actionMap.put(wechat, order - payByWechat(order));適合輕量、單方法的場(chǎng)景。缺點(diǎn)是可擴(kuò)展性弱多個(gè)方法時(shí) Function 表達(dá)不了業(yè)務(wù)邏輯復(fù)雜了還得回到顯式接口。規(guī)則引擎。當(dāng)分支條件不再是簡(jiǎn)單的channel.equals(...)而是多維度組合、幾十上百條規(guī)則時(shí)策略模式也會(huì)力不從心。規(guī)則引擎Drools、Easy Rules 之類可以把條件和動(dòng)作解耦得更徹底但引入成本高一般項(xiàng)目到不了這個(gè)量級(jí)不要輕易用。6.3 我的選型原則決策樹綜合多年實(shí)踐我在決定要不要用策略模式時(shí)腦子里其實(shí)是一個(gè)簡(jiǎn)單的決策樹分支數(shù)量超過 4 個(gè)且未來有明確的增長(zhǎng)預(yù)期——是考慮策略模式。分支邏輯是否超過 10 行——是值得拆如果每個(gè)分支只有一兩行先忍住。分支是否是互斥選擇而非都要執(zhí)行——是適用策略模式不是考慮責(zé)任鏈。各分支之間是否共享復(fù)雜的上下文狀態(tài)——是慎用策略模式。團(tuán)隊(duì)內(nèi)是否都熟悉 Spring 集合注入——如果只有你懂你寫的代碼再好三個(gè)月后沒人敢動(dòng)也是隱患。這套決策邏輯幫我避免了很多次為了炫技而踩坑的沖動(dòng)。技術(shù)選型永遠(yuǎn)不是哪種模式最優(yōu)雅而是哪種模式在團(tuán)隊(duì)的長(zhǎng)期維護(hù)成本里最劃算。寫到最后的一點(diǎn)點(diǎn)個(gè)人經(jīng)驗(yàn)這次重構(gòu)做完之后我最大的感受是策略模式 Spring 自動(dòng)裝配這套組合真正的價(jià)值不是消除了 if-else 這個(gè)表面結(jié)果而是改變了代碼的增長(zhǎng)方式。以前每加一個(gè)渠道是在給一個(gè)已經(jīng)有 200 行的老房子加一層地板現(xiàn)在每加一個(gè)渠道是給一棵樹添一根獨(dú)立的樹枝。新增代碼不需要擔(dān)心碰壞舊邏輯測(cè)試時(shí)也只需要盯著新策略類本身。如果你準(zhǔn)備動(dòng)手重構(gòu)類似的代碼我的建議是先別急著寫代碼花十分鐘把現(xiàn)有 if-else 的每個(gè)分支列出來找出穩(wěn)定的流程骨架和變化點(diǎn)把接口方法設(shè)計(jì)想清楚再動(dòng)手。接口設(shè)計(jì)對(duì)了后面所有實(shí)現(xiàn)類都是水到渠成的事接口設(shè)計(jì)錯(cuò)了后面會(huì)有更多的 if-else 等著你。祝你好運(yùn)希望下次代碼評(píng)審時(shí)你也敢自信地說這個(gè)方法已經(jīng)不需要再改了。