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