本文的重點在於說明工作中所使用的設計模式,為了能夠更好的理解設計模式,首先簡單介紹一下業務場景。使用設計模式,可以簡化代碼、提高擴展性、可維護性和復用性。有哪些設計模式,這裡就不再介紹了,網上很多,本文只介紹所用到設計模式。 ...
本文的重點在於說明工作中所使用的設計模式,為了能夠更好的理解設計模式,首先簡單介紹一下業務場景。使用設計模式,可以簡化代碼、提高擴展性、可維護性和復用性。有哪些設計模式,這裡就不再介紹了,網上很多,本文只介紹所用到設計模式。
一 線路檢查工具
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 * */ @Override public <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{ @Override public <T> void runDataCheck(List<T> resultList, DataCheckRequestDTO requestDTO){ //自己的檢查邏輯 } } /** * 檢查區域內落地配必須三級全覆蓋 * @author xxx * @since xxx * */ public class CheckLandingCoverAreaService extends AbstractDataCheckProductService{ @Override public <T> void runDataCheck(List<T> resultList, DataCheckRequestDTO requestDTO){ //自己的檢查邏輯 } } /** * 檢查資源映射和編碼映射一致 * @author xxx * @since xxx * */ public class CheckAncPathNoServiceService extends AbstractDataCheckProductService{ @Override public <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{ @Override public <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{ @Override public <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{ @Override public <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{ @Override public <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 **************************/ @Resource private LandingCoverAreaDetailStrategy landingCoverAreaDetailStrategy; @Resource private SupplierAndCodeMappingDetailStrategy supplierAndCodeMappingDetailStrategy; /************************ 統計結果的bean **************************/ @Resource private LandingCoverAreaStatisticsStrategy landingCoverAreaStatisticsStrategy; @Resource private 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 { @Override public <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)中。 -
三 思考&感悟
在做這個項目的過程中,剛開始沒有很好的設計,也沒有想的很全面,導致代碼改了又改,雖然耽誤點時間,但覺得是值得的。總結以下幾點:
-
將提升代碼可讀性、可擴展性和可維護性的意識註入到平時的項目中,便於自己,利於他人。如果項目緊急沒時間考慮很多,希望之後有時間時能夠改善和優化。
-
工作不僅是為了完成任務,更是提升自己的過程。能力要用將來進行時。
作者:興亮
本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/Application-of-Design-Pattern-in-Business-System.html