乾貨閱讀 | 設計模式在業務系統中的應用

語言: CN / TW / HK

作者 | 興亮

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

線路檢查工具

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)中。

思考&感悟

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

  • 將提升程式碼可讀性、可擴充套件性和可維護性的意識注入到平時的專案中,便於自己,利於他人。如果專案緊急沒時間考慮很多,希望之後有時間時能夠改善和優化。

  • 工作不僅是為了完成任務,更是提升自己的過程。能力要用將來進行時。

    (END)

福利大放送

開發者如何自我提升?如何拓展自身技能,瞭解最優學習路徑迅速入門?阿里雲 Serverless 免費開放超全開發者學習資料,將最前沿的技術知識沉澱送給各位,內含:技術電子書、技術大會資料合集、知識圖譜、18 節入門影片課等,助力所有開發者共同學習進步!

關注公眾號後臺回覆  學習  即可獲得開發者學習資料下載連結!

  點選“閱讀原文”,還可免費下載電子書!