簡介：?本文的重點在于說明工作中所使用的設計模式，為了能夠更好的理解設計模式，首先簡單介紹一下業務場景。使用設計模式，可以簡化代碼、提高擴展性、可維護性和復用性。有哪些設計模式，這里就不再介紹了，網上很多，本文只介紹所用到設計模式。

作者 | 興亮
來源 | 阿里技術公眾號

本文的重點在于說明工作中所使用的設計模式，為了能夠更好的理解設計模式，首先簡單介紹一下業務場景。使用設計模式，可以簡化代碼、提高擴展性、可維護性和復用性。有哪些設計模式，這里就不再介紹了，網上很多，本文只介紹所用到設計模式。

一 線路檢查工具

1 意義

為什么需要線路檢查工具呢，有以下幾個方面的原因：

• 每逢大促都需要進行各網絡和各行業的線路調整，調整完成之后，是否得到期望狀態，需要檢查確認。
• 上下游應用之間數據的一致性檢查，如果存在不一致，可能會在訂單履行時造成卡單。
• 有些問題發生后，業務同學需要全面檢查一遍線路數據，判斷是否符合預期。
• 各領域之間的數據變更缺乏聯動性，導致資源和線路出現不一致。

為什么要把線路檢查工具產品化呢，考慮如下：

• 以前每次大促，都是技術同學現場編寫代碼撈數據給到業務同學，而且因為人員流動性較大，代碼可復用性較低，導致重復勞動。產品化后，可以方便地傳承下去，避免不必要的重復勞動。
• 每次因為時間緊急，現場寫的代碼都比較簡單，經常是直接將數據打印到標準輸出，然后復制出來，人工拆分轉成Excel格式；這樣的過程要進行多次，占用太多技術同學的時間。產品化后，解放了技術同學，業務同學可以自己在頁面操作。
• 很多數據檢查，是每次大促都會進行的，業務同學與技術同學之間來回溝通的成本較高。產品化后，可以避免這些耗時耗力的溝通，大家可以把更多的時間放在其他的大促保障工作上。

2 檢查項

根據2020年D11進行的數據檢查，本次共實現8項，下面列舉了4項，如下：

• 時效對齊檢查：確保履行分單正常。
• 弱控線路與表達網絡一致性：確保履行和路由不會因為線路缺失而卡單。
• 資源映射和編碼映射一致：前者是表達線路時所用，后者是訂單履約時所用，確保表達和履約能夠一致。
• 檢查線路數量：統計現存線路的情況。

好了，了解了背景知識，下面開始介紹所用到的設計模式，以及為什么要用、怎么用。

二 設計模式

1 模板方法模式+泛型

上述8項數據檢查工具，大致的處理流程是類似的，如下：

針對不同的檢查工具，只有“線路數據檢查”這一步是不一樣的邏輯，其他步驟都是相同的，如果每個檢查工具都實現這么一套邏輯，必定造成大量的重復代碼，維護性較差。

模板方法模式能夠很好地解決這個問題。模板方法設計模式包含模板方法和基本方法，模板方法包含了主要流程；基本方法是流程中共用的邏輯，如創建檢查任務，結果輸出等等。

下圖是所實現的模板方法模式的類繼承關系：

分析如下：

1）DataCheckProductService接口為對外提供的服務，dataCheck方法為統一的數據檢查接口。

2）AbstractDataCheckProductService是一個抽象類，設定模板，即在dataCheck方法中設定好流程，包括如下：

• commonParamCheck方法：進行參數合法性檢查，不合法的情況下，直接返回。
• createFileName方法：創建文件名稱。
• createTaskRecord方法：創建檢查任務。
• runDataCheck方法：進行數據檢查，這是一個抽象方法，所有檢查工具都要實現此方法，以實現自己的邏輯。
• uploadToOSS方法：將檢查結果上傳到OSS，便于下載。
• updateRouteTask方法：結束時更新任務為完成。

dataCheck方法為模板方法，runDataCheck方法由各個子類去實現，其他方法是基本方法。還有一些其他方法，是各個檢查工具都需要使用的，所以就放在了父類中。

3）CheckSupplierAndCodeMappingService類、CheckLandingCoverAreaService類和CheckAncPathNoServiceService類為具體的檢查工具子類，必須實現runDataCheck方法

因為不同檢查項檢的查結果的格式是不一樣的，所以使用了泛型，使得可以兼容不同的檢查結果。

簡化的代碼如下：

/*** 數據檢查工具產品化對外服務接口* @author xxx* @since xxx* */ public interface DataCheckProductService {/*** 數據檢查* @param requestDTO 請求參數* */< T> BaseResult< Long> dataCheck(DataCheckRequestDTO requestDTO); }/*** 數據檢查工具產品化服務** @author xxx* @since xxx* */ public abstract class AbstractDataCheckProductService implements DataCheckProductService {/*** 數據檢查* @param requestDTO 請求參數* @return* */@Overridepublic < T> BaseResult< Long> dataCheck(DataCheckRequestDTO requestDTO){try{//1. 參數合法性檢查Pair< Boolean,String> paramCheckResult = commonParamCheck(requestDTO);if(!paramCheckResult.getLeft()){return BaseResult.ofFail(paramCheckResult.getRight());}//2. 創建導出任務String fileName = createFileName(requestDTO);RouteTaskRecordDO taskRecordDO = createTaskRecord(fileName, requestDTO.getUserName());//3. 進行數據檢查List< T> resultList = Collections.synchronizedList(new ArrayList<>());runDataCheck(resultList, requestDTO);//4. 寫入文件String ossUrl = uploadToOSS(fileName,resultList);//5. 更新任務為完成狀態updateRouteTask(taskRecordDO.getId(),DDportTaskStatus.FINISHED.intValue(), resultList.size()-1,"",ossUrl);return BaseResult.ofSuccess(taskRecordDO.getId());}catch (Exception e){LogPrinter.errorLog("dataCheck-error, beanName="+getBeanName(),e);return BaseResult.ofFail(e.getMessage());}}/*** 進行數據檢查* @param resultList 存放檢查結果* @param requestDTO 請求參數* @return* */public abstract < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO); }/*** 檢查資源映射和編碼映射一致* @author xxx* @since xxx* */ public class CheckSupplierAndCodeMappingService extends AbstractDataCheckProductService{@Overridepublic < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO){//自己的檢查邏輯} }/*** 檢查區域內落地配必須三級全覆蓋* @author xxx* @since xxx* */ public class CheckLandingCoverAreaService extends AbstractDataCheckProductService{@Overridepublic < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO){//自己的檢查邏輯} }/*** 檢查資源映射和編碼映射一致* @author xxx* @since xxx* */ public class CheckAncPathNoServiceService extends AbstractDataCheckProductService{@Overridepublic < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO){//自己的檢查邏輯} }

使用模板方法模式的好處是：

• 簡化了代碼，每個工具只需要關心自己的核心檢查邏輯，不需要關注前置和后置操作。
• 提高了擴展性，可以方便地增加新的檢查工具。
• 統一的異常捕獲和處理邏輯，子類有異常，盡管往外拋出。

2 策略模式

之所以會用到策略模式，是因為一些檢查工具寫完之后，發現跑出來的結果數據太多，有幾萬、幾十萬等等，一方面，檢查比較耗時，結果文件會很大，下載耗時；另一方面，這么多數據給到業務同學，他們也很難處理和分析，也許他們只是想看一下總體情況，并不想看具體的到哪個地方的線路。為此，在原先方案設計的基礎上，增加了“統計信息”的選項，讓用戶可以自行選擇“詳細信息”還是“統計信息”，對應到頁面上就是一個單選框，如下：

現在增加了一種檢查方式，今后是否還會有其他的檢查方式？完全有可能的。所以得考慮到擴展性，便于后面同學增加新的檢查方式。

此外，還有一種場景也可以使用策略模式，那就是業務系統中有很多業務網絡，不同網絡之間有一些差異；本次所實現的檢查工具，有幾個涉及到多個網絡，今后可能會涉及到所有網絡。

綜合以上兩種場景，最合適的就是策略模式了。“詳細信息”和“統計信息”各采用一種策略，不同網絡使用不同的策略，既便于代碼理解，又便于后續擴展。

“詳細信息”和“統計信息”兩種檢查結果的策略類圖如下：

解析：

• CompareModeStrategy對外提供統一的結果處理接口doHandle，策略子類必須實現此接口。
• SupplierAndCodeMappingStatisticsStrategy和SupplierAndCodeMappingDetailStrategy是檢查配送資源和編碼映射一致性的兩種結果信息方式，前者為統計方式，后者為詳細方式。
• LandingCoverAreaStatisticsStrategy和LandingCoverAreaDetailStrategy是檢查落地配覆蓋范圍的兩種結果信息方式，前者為統計方式，后者為詳細方式。
• 那AbstractCompareModeStrategy是干什么用的？它是一個抽象類，負責承接所有策略子類共用的一些方法。

簡化的代碼如下：

/*** 檢查結果策略對外接口* @author xxx* @since xxx* */ public interface CompareModeStrategy {/*** 具體操作** @param list* @param requestDTO* @return 結果集* */< T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO); }/*** 策略公共父類** @author xxx* @since xxx* @apiNote 主要是將子類共用方法和成員抽離出來* */ public abstract class AbstractCompareModeStrategy implements CompareModeStrategy {//子類的共用方法，可以放在此類中 }/*** 檢查落地配覆蓋范圍 詳細信息 策略類* @author xxx* @since xxx* */ public class LandingCoverAreaDetailStrategy extends AbstractCompareModeStrategy{@Overridepublic < T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO){List< T> resultList = new ArrayList<>();//檢查結果處理邏輯return resultList;} }/*** 檢查落地配覆蓋范圍 統計信息 策略類* @author xxx* @since xxx* */ public class LandingCoverAreaStatisticsStrategy extends AbstractCompareModeStrategy{@Overridepublic < T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO){List< T> resultList = new ArrayList<>();//檢查結果處理邏輯return resultList;} }/*** 檢查配送資源和編碼映射一致 詳細信息 策略類* @author xxx* @since xxx* */ public class SupplierAndCodeMappingDetailStrategy extends AbstractCompareModeStrategy{@Overridepublic < T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO){List< T> resultList = new ArrayList<>();//檢查結果處理邏輯return resultList;} }/*** 檢查配送資源和編碼映射一致 統計信息 策略類* @author xxx* @since xxx* */ public class SupplierAndCodeMappingStatisticsStrategy extends AbstractCompareModeStrategy{@Overridepublic < T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO){List< T> resultList = new ArrayList<>();//檢查結果處理邏輯return resultList;} }

同樣，不同網絡的處理策略類圖如下：

代碼與上面類似，就不展示了。

使用策略模式的好處是：

• 提高代碼擴展性，后續增加別的結果格式或別的網絡處理邏輯，可以在不修改其他策略的情況下直接新增。
• 提高代碼可讀性，取代了if...else，條理清晰。
• 不同系列采用不同的策略，策略與策略之間可以嵌套使用，形成策略的疊加效用。

3 工廠模式

工廠模式解決的是bean的生產問題，簡單工廠模式根據入參生產不同的bean，普通工廠模式針對每個bean都構建一個工廠，此兩者各有優劣，看需要。本方案采用的是簡單工廠模式。

之所以使用工廠模式，是因為有太多的bean需要構造，如果在業務邏輯中構造各種bean，則會顯得凌亂和分散，所以需要一個統一生成bean的地方，更好地管理和擴展。

本方案中主要有三類bean需要工廠來生成：

• 模板方法模式中所用到的子類。
• 檢查結果格式策略中所用到的子類。
• 不同網絡處理策略中所用到的子類。

所以，使用三個工廠分別構造這三種類型的bean。另外，因為每個bean主要的功能都在方法中，不涉及類變量的使用，所以可以利用spring容器生成的bean，而不是我們自己new出來，這樣就使得bean可以重復使用。因此，這里的工廠只是bean的決策（根據參數決定使用哪個bean），不用自己new了。

三個工廠分別如下：

• DataCheckProductFatory：由getDataCheckProductService方法根據輸入參數決策使用哪個數據檢查工具。
• CompareModeStrategyFactory：用于決策使用哪種格式輸出，因為將輸出策略分為了2類（詳細信息和統計信息），所以需要傳入兩個參數才能決定使用哪種策略。
• DataCheckNetworkStrategyFactory：用于決策使用哪種網絡處理策略，因為將策略分為了2類（4PL網絡和其他網絡），所以需要傳入兩個參數才能決定使用哪種策略。

這三個工廠的代碼類似，這里就以CompareModeStrategyFactory為例，簡化的代碼如下：

/*** 比對結果集方式* @author xxx* @since xxx* */ @Service public class CompareModeStrategyFactory {/************************ 詳細結果的bean **************************/@Resourceprivate LandingCoverAreaDetailStrategy landingCoverAreaDetailStrategy;@Resourceprivate SupplierAndCodeMappingDetailStrategy supplierAndCodeMappingDetailStrategy;/************************ 統計結果的bean **************************/@Resourceprivate LandingCoverAreaStatisticsStrategy landingCoverAreaStatisticsStrategy;@Resourceprivate SupplierAndCodeMappingStatisticsStrategy supplierAndCodeMappingStatisticsStrategy;/*** 獲取比對結果的策略* */public CompareModeStrategy getCompareModeStrategy(DataCheckProductEnum productEnum, DataCompareModeEnum modeEnum){CompareModeStrategy compareModeStrategy = null;switch (modeEnum){case DETAIL_INFO:compareModeStrategy = getDetailCompareModeStrategy(productEnum);break;case STATISTICS_INFO :compareModeStrategy = getStatisticsCompareModeStrategy(productEnum);break;default:;}return compareModeStrategy;}/*** 獲取 信息信息 策略對象* */private CompareModeStrategy getDetailCompareModeStrategy(DataCheckProductEnum productEnum){CompareModeStrategy compareModeStrategy = null;switch (productEnum){case CHECK_LANDING_COVER_AREA:compareModeStrategy = landingCoverAreaDetailStrategy;break;case CHECK_SUPPLIER_AND_CODE_MAPPING:compareModeStrategy = supplierAndCodeMappingDetailStrategy;break;default:;}return compareModeStrategy;}/*** 獲取 統計信息 策略對象* */private CompareModeStrategy getStatisticsCompareModeStrategy(DataCheckProductEnum productEnum){CompareModeStrategy compareModeStrategy = null;switch (productEnum){case CHECK_LANDING_COVER_AREA:compareModeStrategy = landingCoverAreaStatisticsStrategy;break;case CHECK_SUPPLIER_AND_CODE_MAPPING:compareModeStrategy = supplierAndCodeMappingStatisticsStrategy;break;default:;}return compareModeStrategy;} }

使用工廠模式的好處是：

• 便于bean的管理，所有的bean都在一處創建（或決策）。
• 條理清晰，便于閱讀和維護。

4 “代理模式”

這個代理模式是打著雙引號的，因為不是真正的代理模式，只是從實現方式上來說，具有代理模式的意思。為什么需要用到代理模式？是因為類太多了，業務邏輯分散在各個類中，有的在模板子類中，有的在網絡策略中，有的在結果輸出格式策略中，而這些業務邏輯都需要多線程執行和異常捕獲。如果有個代理類，能夠收口這些處理邏輯，只需增加前置多線程處理和后置異常處理即可。

Java語言中的函數式編程，具備這種能力。所謂函數式編程，是指能夠將方法當做參數傳遞給方法，前面“方法”是業務邏輯，后面“方法”是代理，將業務邏輯傳遞給代理，就實現了統一收口的目的。

能夠實現此功能的接口有四個，分別是：Consumer、Supplier、Predicate與Function，怎么使用可以網上查詢。本方案使用的是Consumer，因為它是用來消費的，即需要傳入一個參數，沒有返回值，符合本方案的設計。

簡化后的代碼如下：

@Service public class CheckLandingCoverAreaService extends AbstractDataCheckProductService {@Overridepublic < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO){dataCheckUtils.parallelCheckByFromResCodes(requestDTO,requestDTO.getFromResCodeList(),fromResCode->{ExpressNetworkQuery query = new ExpressNetworkQuery();query.setNs(NssEnum.PUB.getId());query.setStatus(StatusEnum.ENABLE.getId());query.setGroupNameList(requestDTO.getGroupNameList());query.setBrandCodeList(requestDTO.getBrandCodeList());query.setFromResCode(fromResCode);List< TmsMasterExpressNetworkDO> masterExpressNetworkDOS = tmsMasterExpressNetworkService.queryExpressNetworkTimeList(query);startCompareWithAnc(resultList,requestDTO,masterExpressNetworkDOS,fromResCode,solutionCodeMap);});} }@Service public class DataCheckUtils {/*** 并行處理每個倉* @param requestDTO 請求參數* @param fromResCodeList 需要檢查的倉列表* @param checkOperation 具體的業務處理邏輯* */public < T> void parallelCheckByFromResCodes(DataCheckRequestDTO requestDTO, List< String> fromResCodeList, Consumer< String> checkOperation){List< CompletableFuture> futureList = Collections.synchronizedList(new ArrayList<>());fromResCodeList.forEach(fromResCode->{CompletableFuture future = CompletableFuture.runAsync(() -> {try{checkOperation.accept(fromResCode);}catch (Exception e){LogPrinter.errorLog("parallelCheckByFromResCodes-error, taskId="+requestDTO.getTaskId(),e);recordErrorInfo(requestDTO.getTaskId(),e);}}, DATA_CHECK_THREAD_POOL);futureList.add(future);});//等待所有線程結束futureList.forEach(future->{try{future.get();}catch (Exception e){LogPrinter.errorLog("parallelCheckByFromResCodes-future-get-error",e);}});} }

可以看出，Consumer所代表的就是一個方法，將此方法作為parallelCheckByFromResCodes方法的一個參數，在parallelCheckByFromResCodes中進行多線程和異常處理，既能統一收口，又大大減少了重復代碼。

代理模式的好處是：

• 統一收口多種不同的業務邏輯，統一做日志和異常處理。
• 減少重復代碼，提高了代碼質量。
• 可維護性較強。

5 其他

像結果輸出格式策略模式那樣，雖然AbstractCompareModeStrategy沒有實際的業務邏輯，但仍然把它作為一個基類，目的是所有子類共用的邏輯或方法，能夠放在此類中，減少代碼量，提升維護性。

但是有的時候，不是繼承自同一個基類的子類們，仍然要共用一些邏輯或方法（如parallelCheckByFromResCodes方法），但Java語言限制一個類只能繼承一個基類，怎么辦呢？簡單的辦法就是把這些共用邏輯或方法放到一個工具類（如DataCheckUtils）中。

三 思考&感悟

在做這個項目的過程中，剛開始沒有很好的設計，也沒有想的很全面，導致代碼改了又改，雖然耽誤點時間，但覺得是值得的。總結以下幾點：

• 將提升代碼可讀性、可擴展性和可維護性的意識注入到平時的項目中，便于自己，利于他人。如果項目緊急沒時間考慮很多，希望之后有時間時能夠改善和優化。
• 工作不僅是為了完成任務，更是提升自己的過程。能力要用將來進行時。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的设计模式在业务系统中的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。