背景

最近開發了一個需求，該接口需要根據 p1、p2、p3、version 多個入參的不同組合按照其對應的業務策略給出結果數據。由於該接口已經開發了三期了，每次開發新一期的需求時爲了兼容老的業務邏輯，大家都傾向於不刪不改只新增，因此這塊代碼已經產生了一些「壞味道」，函數入口通過不斷添加「衛語句」判斷 version 的方式跳轉到新一期的業務邏輯方法中，而每一期的業務邏輯也是通過 p1、p2、p3 的 if-else 組合形成不同的分支邏輯。這已經是我簡化後的表述，總之剛開始對於我這個新同學來說，梳理這塊業務代碼着實花了一些功夫。

而且，這塊邏輯相當於是一個業務上的通用能力，未來一定還會有五期、六期、N 期的需求進來，入參的取值也會不斷拓展，因此以現有方式膨脹下去只會壞味道會越來越重。

總結一下，當前場景面臨的問題是：

• 如何解決接口升級，在保證兼容老版本的情況下輕鬆開發新版本業務邏輯？

• 如何根據入參 p1、p2、p3 等的不同組合進行策略定位？

思路

在思考解決方案時，很容易想到兩種可以優化類似場景的設計模式：責任鏈模式和策略模式。

責任鏈模式

責任鏈模式是實現了類似「流水線」結構的逐級處理，通常是一條鏈式結構，將「抽象處理者」的不同實現串聯起來：如果當前節點能夠處理任務則直接處理掉，如果無法處理則委託給責任鏈的下一個節點，如此往復直到有節點可以處理這個任務。

我們可以通過責任鏈模式完成對不同 version 業務邏輯隔離的處理，比如節點 1 處理 version = 1 的請求，節點 2 處理 version = 2 的請求等等。但問題在於我們遇到的場景還需要根據一定策略，路由到不同的下游節點進行處理。這就是策略模式擅長解決的問題了。

策略模式

策略模式的目的是將算法的使用與定義解耦，能夠實現根據規則路由到不同策略類進行處理。

我們可以通過策略模式解決根據不同參數組合執行不同業務邏輯的場景。但是我們的場景僅僅通過一層策略路由無法滿足任務處理需求。請求的分層處理又是責任鏈模式所擅長的了。

可以看到，兩種設計模式都不完全符合目前這個場景：責任鏈模式可以實現逐級委託，但每一級又不能像策略模式那樣路由到不同的處理者上；策略模式通常只有一層路由，不易實現多個參數的策略組合。

因此我們自然而然地可以想到：是不是可以將兩種模式結合起來？

廣義責任鏈——責任樹模式

將責任鏈與策略模式融合，即成爲了一種廣義的責任鏈模式，我簡稱爲「責任樹模式」。這種模式不僅可以完成任務的逐級委託，也可以在任一級選擇不同的下游策略進行處理。

那麼問題來了，如何通過責任樹模式解決前面我們遇到的問題呢？

首先看如何解決第一個問題，新老接口的隔離 & 兼容：可以將接口每個版本的邏輯作爲一個責任樹上第一層的不同實現，如分別對應上圖中的 Strategy1、Strategy2、Strategy3 節點。這樣在接口入口，就首先把策略路由到不同的分支上去。如果沒有節點命中，則不再向下游委託直接返回錯誤。

然後第二個問題，參數的組合定位到不同的策略實現上：同樣的思路，一個參數對應責任樹上的一層的路由，將該參數的不同取值路由到下一層的不同實現即可，這樣逐級委託，後面新增入參的枚舉值、甚至再拓展新的入參都可以非常方便地進行拓展。

獲得收益

將這塊業務通過「責任樹模式」重構之後，已經收穫以下幾個收益點：

• 代碼結構更清晰，可維護性提升：沒有了各種衛語句的跳轉 & 維護性巨差的巨型方法，函數可以收斂在理想的 50 行內；

• 調試階段問題易定位：同樣由於策略間隔離，調試時可以直接定位到指定策略的業務邏輯代碼，不需要逐句排查；

同時長遠來看，也可以持續獲得如下收益：

• 後續迭代人力成本降低；

• 新增需求修改代碼不易出錯：策略間隔離，不需要完整看一遍大函數理清邏輯再修改，只需要無腦添加一條路由 + 新的策略實現方法即可；

相信有開發經驗的同學應該都有體會，即使是自己寫過的代碼，一陣子不看也會忘掉，等到再有修改時，還要順着代碼理一遍邏輯，如果文檔、註釋沒寫好，那就更加酸爽了。因此，將巨型函數拆分解耦非常重要。

抽象框架

雖然通過「責任樹模式」解決了我這個需求開發中遇到的問題，但是類似的問題還是普遍存在的。本着助（shǎo）人（zào）爲（lún）樂（zi）的精神，我更進一步，將責任樹模式抽象出一個通用的框架，方便大家在遇到類似問題時快速「種樹」。

這個框架由一個 Router 和 Handler 組成：

• Router 是一個抽象類，負責定義如何路由到下游的多個子節點；

• Handler 是接口，負責實現每個節點的業務邏輯。

我們可以非常方便地通過 Router 和 Handler 的組合拼裝成整棵樹的結構。

從圖中我們可以看出以下幾個要點：

• 除了根節點（入口）外，每個節點都實現了 Handler 接口。根節點只繼承 Router 抽象類；

• 所有葉子節點只實現 Handler 接口而無需繼承 Router 抽象類（無需再向下委託）；

• 除了根節點和葉子節點外的其他節點，都是上一層的 Handler，同時是下一層的 Router；

那麼我們話不多說，先看下框架代碼。

AbstractStrategyRouter抽象類

@Component
public abstract class AbstractStrategyRouter<T, R> {

    public interface StrategyMapper<T, R> {
        StrategyHandler<T, R> get(T param);
    }

    private StrategyMapper<T, R> strategyMapper;

    @PostConstruct
    private void abstractInit() {
        strategyMapper = registerStrategyMapper();
        Objects.requireNonNull(strategyMapper, "strategyMapper cannot be null");
    }

    @Getter
    @Setter
    @SuppressWarnings("unchecked")
    private StrategyHandler<T, R> defaultStrategyHandler = StrategyHandler.DEFAULT;

    public R applyStrategy(T param) {
        final StrategyHandler<T, R> strategyHandler = strategyMapper.get(param);
        if (strategyHandler != null) {
            return strategyHandler.apply(param);
        }

        return defaultStrategyHandler.apply(param);
    }

    protected abstract StrategyMapper<T, R> registerStrategyMapper();
}

如果子節點路由邏輯比較簡單，可以直接通過 if-else 進行分發。 當然如果爲了更好地性能、適應更復雜的分發邏輯也可以使用 Map 等保存映射。

對於實現了該抽象類的 Router 節點，只需要調用其 publicR applyStrategy(T param) 方法即可獲取該節點的期望輸出。框架會自動根據定義的路由邏輯將 param 傳遞到對應的子節點，再由子節點不斷向下分發直到葉子節點或可以給出業務輸出的一層。這個過程有點類似遞歸或者分治的思想。

StrategyHandler接口

對於其他責任樹中的中間層節點，都需要同時繼承 Router 抽象類和實現 Handler 接口，在 R apply(T param); 方法中首先進行一定異常入參攔截，遵循 fail-fast 原則，避免將這一層可以攔截的錯誤傳遞到下一層，同時也要避免「越權」做非本層職責的攔截校驗，避免產生耦合，爲後面業務拓展挖坑。在攔截邏輯後直接調用本身 Router 的 publicR applyStrategy(T param) 方法路由給下游節點即可。

至此，關於如何通過「責任樹模式」優化這個需求場景的介紹就基本結束了，這不是一個複雜的需求，更不是一個多麼精妙的優化，這只是日常需求開發中通過設計模式優化代碼的一個小例子。

最後再簡單聊聊我在日常需求開發過程中關於架構設計部分的一些思考。

其實並不是說用「if-else」很 Low，用設計模式就 Niubility，二者各有其擅長的應用場景，在合適的場景使用合適的代碼纔是正道。其實「if-else」足以滿足大部分日常需求的開發，且簡單、靈活、可靠。這裏的「if-else」泛指樸素直白的編程模式，僅以實現需求業務功能爲目的的編碼方式。當然，有些同學不滿足於此，希望可以通過經過思考的、更優的架構設計使代碼變的更簡潔、拓展性更好、性能更優、可讀性更好等等。不過對於此也存在反對的論述，謂之「過早優化乃萬惡之源」。

這句話源自 Donald Knuth 老人家：

這句話我當然承認其正確性，但我同樣覺得需要注意以下幾點：

1. 任何「結論」都有其所處背景、上下文細節等，通過一句話指導工作是不成立的。優秀的架構師可以給出架構設計是在理論基礎、大量實踐、不斷思考總結以及無數採坑的經驗的基礎上得來的，而不是他知道一句別人都不知道的「咒語」；

2. Knuth 這句話更偏重於反對奇技淫巧、細枝末節的性能優化，因爲在「過早」的時候無法準確獲知系統的瓶頸且局部的優化不僅不能帶來收益，反而會造成更大的代價。他批評的恰恰是不着眼於整體架構的局部視角對系統的破壞，而架構設計正是需要從整體視角去做選擇與權衡。因此將 Knuth 這句話直接推廣到「架構設計」上並不妥當；

3. 很多人覺得在項目開發時需求經常「瞬息萬變」、「朝令夕改」，而做優化又需要花費大量時間思考，根本沒有精力優化。我認爲這種論述也是不成立的，憑什麼認爲等到壞味道嚴重、歷史包袱沉重的時候就有精力、能力和膽量做優化了呢？

4. 何時是所謂的「不早」很難界定，其實我們永遠都無法確定自己掌握了足夠的細節可以進行絕對正確的優化。在現實世界中，受到時間維度的限制，我們永遠無法達成全局最優，只能以局部最優不斷去逼近全局最優。我覺得等到壞味道嚴重不得不重構的時候纔想起優化已爲時過晚；

5. 這句話不應該成爲不做設計的藉口，即使最終提交的代碼仍是「if-else」版本，也不應省略思考、推演、權衡的過程，日常需求是練兵場，是精進技術的必經之路；

所以，我覺得不要被這句話束縛手腳，當然更不要閉門造車，在開發過程中勤于思考，向更有經驗的人請教，在架構設計上不斷學習、探索，才能擺脫日復一日通過「if-else」堆砌業務邏輯的循環。

相關文章