大多數時候我都是寫一些業務代碼，可能一堆 CRUD 就能解決問題，但是這樣的工作對技術人的提升并不多，如何讓自己從業務中解脫出來找到寫代碼的樂趣呢，我做過一些嘗試，使用設計模式改善自己的業務代碼就是其中的一種。

 

[[345303]] 

圖片來自 Pexels

“你這代碼寫的像坨屎”，今天我的代碼又被當作典型被 CTO 罵了......于是他給我的建議如下：

責任鏈設計模式

模式定義

請求在一個鏈條上處理，鏈條上的受理者處理完畢之后決定是繼續往后傳遞還是中斷當前處理流程。

適用場景

適用于多節點的流程處理，每個節點完成各自負責的部分，節點之間不知道彼此的存在，比如 OA 的審批流，Java Web 開發中的 Filter 機制。

舉一個生活中的例子，筆者之前租房的時候遇到了所謂的黑中介，租的時候感覺自己是上帝，但是壞了東西找他修的時候就像個孫子一樣。

中介讓我找門店客服，門店客服又讓我找房東，房東又讓我找她家老公，最終好說歹說才把這事了了(租房一定要找正規中介)。

實踐經驗

筆者目前所做的業務是校園團餐的聚合支付，業務流程很簡單：

• 學生打開手機付款碼支付。
• 食堂大媽使用機具掃付款碼收款。

大學食堂有個背景是這樣的，食堂有補貼，菜品比較便宜，所以學校是不愿意讓社會人士去學校食堂消費的，鑒于此，我們在支付之前加了一套是否允許支付的檢驗邏輯。

大體如下：

• 某檔口只允許某類用戶用戶消費，比如教師檔口只允許教師消費，學生檔口不允許校外用戶消費。
• 某個檔口一天只允許某類用戶消費幾次，比如教師食堂一天只允許學生消費一次。
• 是否允許非清真學生消費，比如某些清真餐廳，是不允許非清真學生消費的。

針對這幾類情況我建立了三類過濾器，分別是：

• SpecificCardUserConsumeLimitFilter：按用戶類型判斷是否允許消費。
• DayConsumeTimesConsumeLimitFilter：按日消費次數判斷是否允許消費。
• MuslimConsumeLimitFilter：非清真用戶是否允許消費。

判斷邏輯是先通過 SpecificCardUserConsumeLimitFilter 判斷當前用戶是否可以在此檔口消費。

如果允許繼續由 DayConsumeTimesConsumeLimitFilter 判斷當天消費次數是否已用完;如果未用完繼續由 MuslimConsumeLimitFilter 判斷當前用戶是否滿足清真餐廳的就餐條件，前面三條判斷，只要有一個不滿足就提前返回。

部分代碼如下：

public boolean canConsume(String uid,String shopId,String supplierId){ 
    //獲取用戶信息，用戶信息包含類型（student：學生，teacher：老師，unknown：未知用戶）、名族（han：漢族，mg：蒙古族） 
    UserInfo userInfo = getUserInfo(uid); 
    //獲取消費限制信息，限制信息包含是否允許非清真消費、每種類型的用戶是否允許消費以及允許消費的次數 
   ConsumeConfigInfo consumeConfigInfo = getConsumeConfigInfo(shopId,supplierId)  
 
 
    // 構造消費限制過濾器鏈條 
    ConsumeLimitFilterChain filterChain = new ConsumeLimitFilterChain(); 
    filterChain.addFilter(new SpecificCardUserConsumeLimitFilter()); 
    filterChain.addFilter(new DayConsumeTimesConsumeLimitFilter()); 
    filterChain.addFilter(new MuslimConsumeLimitFilter()); 
    boolean checkResult = filterChain.doFilter(filterChain, schoolMemberInfo, consumeConfigInfo); 
 
    //filterChain.doFilter方法 
   public boolean doFilter(ConsumeLimitFilterChain filterChain,UserInfo userInfo, 
             ConsumeConfigInfo consumeConfigInfo ){ 
        //迭代調用過濾器 
        if(index<filters.size()){ 
            return filters.get(index++).doFilter(filterChain, userInfo, consumeConfigInfo); 
        } 
    } 
 
    //SpecificCardUserConsumeLimitFilter.doFilter方法 
     public boolean doFilter(ConsumeLimitFilterChain filterChain,UserInfo userInfo, 
             ConsumeConfigInfo consumeConfigInfo ){ 
                //獲取某一類型的消費限制，比如student允許消費，unknown不允許消費 
        CardConsumeConfig cardConsumeConfig = findSuitCardConfig(userInfo, consumeConfigInfo); 
 
        // 判斷當前卡用戶是否允許消費 
        if (consumeCardConfig != null) { 
            if ((!CAN_PAY.equals(cardConsumeConfig .getEnabledPay()))) { 
                return false; 
            } 
        } 
 
                //其余情況，繼續往后傳遞 
            return filterChain.doFilter(filterChain, memberInfo, consumeConfig); 
        } 
 
    //DayConsumeTimesConsumeLimitFilter.doFilter方法 
     public boolean doFilter(ConsumeLimitFilterChain filterChain,UserInfo userInfo, 
             ConsumeConfigInfo consumeConfigInfo ){ 
                //獲取某一類型的消費限制，比如student可以消費2次 
        CardConsumeConfig cardConsumeConfig = findSuitCardConfig(userInfo, consumeConfigInfo); 
 
                //獲取當前用戶今天的消費次數 
                int consumeCnt = getConsumeCnt(userInfo)         
        if(consumeCnt >= cardConsumeConfig.getDayConsumeTimesLimit()){ 
                    return false; 
                } 
 
                //其余情況，繼續往后傳遞 
                return filterChain.doFilter(filterChain, memberInfo, consumeConfig); 
        } 

總結：將每種限制條件的判斷邏輯封裝到了具體的 Filter 中，如果某種限制條件的邏輯有修改不會影響其他條件，如果需要新加限制條件只需要重新構造一個 Filter 織入到 FilterChain 上即可。

策略設計模式

模式定義

定義一系列的算法，把每一個算法封裝起來，并且使它們可相互替換。

適用場景

主要是為了消除大量的 if else 代碼，將每種判斷背后的算法邏輯提取到具體的策略對象中，當算法邏輯修改時對使用者無感知，只需要修改策略對象內部邏輯即可。

這類策略對象一般都實現了某個共同的接口，可以達到互換的目的。

實踐經驗

筆者之前有個需求是用戶掃碼支付以后向檔口的收銀設備推送一條支付消息，收銀設備收到消息以后會進行語音播報，邏輯很簡單，就是調用推送平臺推送一條消息給設備即可。

但是由于歷史原因，某些設備對接的推送平臺是不一樣的，A 類設備優先使用信鴿推送，如果失敗了需要降級到長輪詢機制，B 類設備直接使用自研的推送平臺即可。

還有個現狀是 A 類和 B 類的消息格式是不一樣的(不同的團隊開發，后期被整合到一起)。

鑒于此，我抽象出 PushStrategy 接口，其具體的實現有 IotPushStrategy 和 XingePushStrategy，分別對應自研推送平臺的推送策略和信鴿平臺的推送策略，使用者時針對不同的設備類型使用不同的推送策略即可。

部分代碼如下：

/** 
 * 推送策略 
 * / 
public interface PushStrategy { 
    /** 
         @param deviceVO設備對象，包扣設備sn，信鴿pushid 
         @param content，推送內容，一般為json 
        */ 
    public CallResult push(AppDeviceVO deviceVO, Object content); 
} 
 
IotPushStrategy implements PushStrategy{ 
        /** 
         @param deviceVO設備對象，包扣設備sn，信鴿pushid 
         @param content，推送內容，一般為json 
        */ 
    public CallResult push(AppDeviceVO deviceVO, Object content){ 
            //創建自研推送平臺需要的推送報文 
            Message message = createPushMsg(deviceVO，content); 
 
            //調用推送平臺推送接口 
            IotMessageService.pushMsg(message); 
        } 
} 
 
XingePushStrategy implements PushStrategy{ 
        /** 
         @param deviceVO設備對象，包扣設備sn，信鴿pushid 
         @param content，推送內容，一般為json 
        */ 
    public CallResult push(AppDeviceVO deviceVO, Object content){ 
            //創建信鴿平臺需要的推送報文 
            JSONObject jsonObject = createPushMsg(content); 
 
            //調用推送平臺推送接口 
            if(!XinggePush.pushMsg(message)){ 
                //降級到長輪詢 
                ... 
            } 
        } 
} 
 
/** 
消息推送Service 
*/ 
MessagePushService{ 
    pushMsg(AppDeviceVO deviceVO, Object content){ 
        if(A設備){ 
            XingePushStrategy.push(deviceVO,content); 
        } else if(B設備）{ 
            IotPushStrategy.push(deviceVO,content); 
        } 
    } 
} 

總結：將每種通道的推送邏輯封裝到了具體的策略中，某種策略的變更不會影響其他策略，由于實現了共同接口，所以策略可以互相替換，對使用者友好。

比如 Java ThreadPoolExecutor 中的任務拒絕策略，當線程池已經飽和的時候會執行拒絕策略，具體的拒絕邏輯被封裝到了 RejectedExecutionHandler 的 rejectedExecution 中。

模板設計模式

模式定義

模板的價值就在于骨架的定義，骨架內部將問題處理的流程已經定義好，通用的處理邏輯一般由父類實現，個性化的處理邏輯由子類實現。

比如炒土豆絲和炒麻婆豆腐，大體邏輯都是：

• 切菜
• 放油
• 炒菜
• 出鍋

1，2，4 都差不多，但是第 3 步是不一樣的，炒土豆絲得拿鏟子翻炒，但是炒麻婆豆腐得拿勺子輕推，否則豆腐會爛(疫情宅在家，學了不少菜)。

使用場景

不同場景的處理流程，部分邏輯是通用的，可以放到父類中作為通用實現，部分邏輯是個性化的，需要子類去個性實現。

實踐經驗

還是接著之前語音播報的例子來說，后期我們新加了兩個需求：

• 消息推送需要增加 trace。
• 有些通道推送失敗需要重試。

所以現在的流程變成了這樣：

• trace 開始。
• 通道開始推送。
• 是否允許重試，如果允許執行重試邏輯。
• trace 結束。

其中 1 和 4 是通用的，2 和 3 是個性化的，鑒于此我在具體的推送策略之前增加了一層父類的策略，將通用邏輯放到了父類中。

修改后的代碼如下：

abstract class AbstractPushStrategy implements PushStrategy{ 
    @Override 
    public CallResult push(AppDeviceVO deviceVO, Object content) { 
        //1.構造span 
        Span span = buildSpan(); 
        //2.具體通道推送邏輯由子類實現 
        CallResult callResult = doPush(deviceVO, content); 
 
        //3.是否允許重試邏輯由子類實現，如果允許執行重試邏輯 
        if(!callResult.isSuccess() && canRetry()){ 
            doPush(deviceVO, content); 
        } 
 
        //4.trace結束 
        span.finish()  
    } 
 
    //具體推送邏輯由子類實現 
    protected abstract CallResult doPush(AppDeviceVO deviceDO, Object content) ; 
 
    //是否允許重試由子類實現，有些通道之前沒有做消息排重，所有不能重試 
    protected abstract boolean canRetry(CallResult callResult); 
 
} 
 
XingePushStrategy extends AbstractPushStrategy{ 
    @Override 
    protected CallResult doPush(AppDeviceVO deviceDO, Object content) { 
        //執行推送邏輯 
    } 
 
    @Override 
    protected boolean canRetry(CallResult callResult){ 
        return false 
    } 
} 

總結：通過模板定義了流程，將通用邏輯放在父類實現，減少了重復代碼，個性化邏輯由子類自己實現，子類間修改代碼互不干擾也不會破壞流程。

觀察者設計模式

模式定義

顧名思義，此模式需要有觀察者(Observer)和被觀察者(Observable)兩類角色。

當 Observable 狀態變化時會通知 Observer，Observer 一般會實現一類通用的接口。

比如 java.util.Observer，Observable 需要通知 Observer 時，逐個調用 Observer 的 update 方法即可，Observer 的處理成功與否不應該影響 Observable 的流程。

使用場景

一個對象(Observable)狀態改變需要通知其他對象，Observer 的存在不影響 Observable 的處理結果，Observer 的增刪對 Observable 無感知。

比如 Kafka 的消息訂閱，Producer 發送一條消息到 Topic，至于是 1 個還是 10 個 Consumer 訂閱這個 Topic，Producer 是不需要關注的。

實踐經驗

在責任鏈設計模式那塊我通過三個 Filter 解決了消費限制檢驗的問題，其中有一個 Filter 是用來檢驗消費次數的，我這里只是讀取用戶的消費次數，那么消費次數的累加是怎么完成的呢?

其實累加這塊就用到了觀察者模式，具體來講是這樣，當交易系統收到支付成功回調時會通過 Spring 的事件機制發布“支付成功事件”。

這樣負責累加消費次數和負責語音播報的訂閱者就會收到“支付成功事件”，進而做各自的業務邏輯。

畫個簡單的圖描述一下：

代碼結構大體如下：

/** 
支付回調處理者 
*/ 
PayCallBackController implements ApplicationContextAware { 
     private ApplicationContext applicationContext; 
 
    //如果想獲取applicationContext需要實現ApplicationContextAware接口，Spring容器會回調setApplicationContext方法將applicationContext注入進來 
    @Override 
    public void setApplicationContext(ApplicationContext applicationContext) 
            throws BeansException { 
        this.applicationContext = applicationContext; 
    } 
     @RequestMapping(value = "/pay/callback.do") 
     public View callback(HttpServletRequest request){ 
        if(paySuccess(request){ 
            //構造支付成功事件 
            PaySuccessEvent event = buildPaySuccessEvent(...); 
            //通過applicationContext發布事件，從而達到通知觀察者的目的 
            this.applicationContext.publishEvent(event); 
        }  
    } 
} 
/** 
 * 語音播報處理者 
 * 
 */ 
public class VoiceBroadcastHandler implements ApplicationListener<PaySuccessEvent>{ 
    @Override 
    public void onApplicationEvent(PaySuccessEvent event) { 
        //語音播報邏輯 
    } 
} 
 
//其他處理者的邏輯類似 

總結：觀察者模式將被觀察者和觀察者之間做了解耦，觀察者存在與否不會影響被觀察者的現有邏輯。

裝飾器設計模式

模式定義

裝飾器用來包裝原有的類，在對使用者透明的情況下做功能的增強，比如 Java 中的 BufferedInputStream 可以對其包裝的 InputStream 做增強，從而提供緩沖功能。

使用場景

希望對原有類的功能做增強，但又不希望增加過多子類時，可以使用裝飾器模式來達到同樣的效果。

實踐經驗

筆者之前在推動整個公司接入 trace 體系，因此也提供了一些工具來解決 trace 的自動織入和上下文的自動傳遞。

為了支持線程間的上下文傳遞，我增加了 TraceRunnableWrapper 這個裝飾類，從而起到將父線程的上下文透傳到子線程中，對使用者完全透明。

代碼如下：

/** 
可以自動攜帶trace上下文的Runnable裝飾器 
*/ 
public class TraceRunnableWrapper implements Runnable{ 
    //被包裝的目標對象 
    private Runnable task; 
    private Span parentSpan = null; 
 
    public TraceRunnableWrapper(Runnable task) { 
        //1.獲取當前線程的上下文（因為new的時候還沒有發生線程切換，所以需要在這里將上下文獲取） 
        //對這塊代碼感興趣的可以查看opentracing API 
        io.opentracing.Scope currentScope = GlobalTracer.get().scopeManager().active(); 
        //2.保存父上下文 
        parentSpan = currentScope.span(); 
        this.task = task; 
    } 
 
    @Override 
    public void run() { 
        //run的時候將父線程的上下文綁定到當前線程 
        io.opentracing.Scope scope = GlobalTracer.get().scopeManager().activate(parentSpan,false); 
        task.run(); 
    } 
} 
 
//使用者 
new Thread(new Runnable(){run(...)}).start()替換為new TraceRunnableWrapper(new Runnable(){run(...)}).start() 

總結：使用裝飾器模式做了功能的增強，對使用者來說只需要做簡單的組合就能繼續使用原功能。

外觀設計模式

模式定義

何為外觀，就是對外提供一個統一的入口：

• 一是可以影藏系統內部的細節。
• 二是可以降低使用者的復雜度。

比如 SpringMVC 中的 DispaterServlet，所有的 Controller 都是通過 DispaterServlet 統一暴露。

使用場景

降低使用者的復雜度，簡化客戶端的接入成本。

實踐經驗

筆者所在的公司對外提供了一些開放能力給第三方 ISV，比如設備管控、統一支付、對賬單下載等能力。

由于分屬于不同的團隊，所以對外提供的接口形式各異，初期還好，接口不多，ISV 也能接受，但是后期接口多了 ISV 就開始抱怨接入成本太高。

為了解決這一問題，我們在開放接口前面加了一層前端控制器 GatewayController，其實就是我們后來開放平臺的雛形。

GatewayController 對外統一暴露一個接口 gateway.do，將對外接口的請求參數和響應參數統一在 GatewayController 做收斂，GatewayController 往后端服務路由時也采用統一接口。

改造前后對比如下圖：

大概代碼如下：

使用者： 
HttpClient.doPost("/gateway.do","{'method':'trade.create','sign':'wxxaaa','timestamp':'15311111111'},'bizContent':'業務參數'") 
 
GatewayController: 
@RequestMapping("/gateway.do") 
JSON gateway(HttpServletRequest req){ 
   //1.組裝開放請求 
   OpenRequest openRequest = buildOpenRequest(req); 
 
   OpenResponse openResponse = null; 
   //2.請求路由 
   if("trade.create".equals(openRequest.getMethod()){ 
       //proxy to trade service by dubbo 
       openResponse = TradeFacade.execute(genericParam); 
   } else if("iot.message.push".equals(openRequest.getMethod()){ 
       //proxy to iot service by httpclient 
        openResponse = HttpClient.doPost('http://iot.service/generic/execute'genericParam); 
   } 
 
   if(openResponse.isSuccess()){ 
        return {"code":"10000","bizContent":openResponse.getResult()}; 
   }else{ 
        return {"code":"20000","bizCode":openResponse.getCode()}; 
   } 
 
 
} 

總結：采用外觀模式屏蔽了系統內部的一些細節，降低了使用者的接入成本。

就拿 GatewayController 來說，ISV 的鑒權，接口的驗簽等重復工作統一由它實現。

ISV 對接不同的接口只需要關心一套接口協議接口，由 GatewayController 這一層做了收斂。

作者：踩刀詩人

編輯：陶家龍

出處：https://urlify.cn/J3mAna