摘要：此案例中，門面類為，然后各個門面方法的參數(shù)均為抽象類，通過決定調用中的哪個子類。抽象類持有類的對象，并且實現(xiàn)累的一個接口是為了容器啟動完成的時候自動把相應的校驗器加入到校驗器鏈中。

引言：很久沒有更新了，主要是工作忙。最近，工作中一個子系統(tǒng)升級，把之前不易擴展的缺點給改進了一下，主要是運用了幾個設計模式進行稍微改造了一下。
本文也同步發(fā)布至簡書，地址： https://www.jianshu.com/p/962...

在公司的一個實際項目中，需要做一個第三方公司（以下簡稱GMG）的系統(tǒng)集成工作，把該公司的一些訂單數(shù)據(jù)集成到自己公司平臺下，各個訂單具有一些共性，但是也有其特有的特征。 經(jīng)過設計，目前我把訂單分為POLICY和BOB類型（暫且這么說吧，反正就是一種訂單類型，大家參照著看就OK）。

在訂單數(shù)據(jù)集成到公司平臺前，需要對訂單數(shù)據(jù)進行一些必要的業(yè)務邏輯校驗操作，并且每個訂單都有自己的校驗邏輯（包含公共的校驗邏輯）。 本節(jié)介紹的便是整個訂單集成系統(tǒng)中的校驗邏輯在綜合利用設計模式的基礎上進行架構設計。

本校驗邏輯主要分為四個部分：

校驗文件名稱（RequestValidator.validateFileInfo）

校驗文件內容中的概要部分（RequestValidator.validateSummary）

校驗文件內容中的列名稱（RequestValidator.validateHeaders）

校驗文件內容中的明細（RequestValidator.validateDetails）

其實上面的RequestValidator的實現(xiàn)邏輯最后都是委托給RequestValidationFacade這個門面類進行相應的校驗操作。

主要分為RequestFile和RequestDetail兩個domain,RequestFile接收泛型的類型（即RequestFile）, 使得其子類能夠自動識別相應的RequestDetail的子類。RequestFile為抽象類，定義了以下抽象方法，由子類實現(xiàn)：

//由子類實現(xiàn)具體的獲取文件明細內容
public abstract List getRequestDetails();
//由子類實現(xiàn)具體的獲取workflow的值
public abstract WorkflowEnum getProcessWorkFlow();
//由子類實現(xiàn)文件列字段名列表
public abstract String[] getDetailHeaders();

RequestDetail及其子類就是workflow對應文件的明細內容。

本例中如下規(guī)定：

workflow為WorkflowEnum.POLICY對應文件名為：csync_policy_yyyyMMdd_HHmmss_count.txt

workflow為WorkflowEnum.BOB對應文件名為：csync_bob_integration_yyyyMMdd_HHmmss_count.txt

以上校驗邏輯在AbstractRequestValidation類相應的子類中實現(xiàn)（validateFileName方法），其實這個枚舉貫穿整個校驗組件，它就是一個針對每個業(yè)務流程定義的一個枚舉策略。

在客戶端調用程序中，采用門面模式進行統(tǒng)一的入口（門面模式講究的是脫離具體的業(yè)務邏輯代碼）。門面模式封裝的結果就是避免高層模塊深入子系統(tǒng)內部，同時提供系統(tǒng)的高內聚、低耦合的特性。

此案例中，門面類為RequestValidationFacade，然后各個門面方法的參數(shù)均為抽象類RequestFile，通過RequestFile->getProcessWorkFlow()決定調用AbstractRequestValidation中的哪個子類。 AbstractRequestValidation類構造方法中定義了如下邏輯：

requestValidationHandlerMap.put(this.accessWorkflow(),this.accessBeanName());

把子類中Spring自動注入的實體bean緩存到requestValidationHandlerMap中，key即為WorkflowEnum枚舉值，value為spring bean name, 然后在門面類中可以通過對應的枚舉值取得BeanName，進而得到AbstractRequestValidation相應的子類對象，進行相應的校驗操作。

注：這邊動態(tài)調用到AbstractRequestValidation相應的子類對象，其實也是隱藏著【策略模式】的影子。

類圖如下：

在具體的校驗邏輯中，用到核心設計模式便是模版方法模式，AbstractRequestValidation抽象類中定義了以下抽象方法：

 /**
     * validate the file details
     * @param errMsg
     * @param requestFile
     * @return
     */
    protected abstract StringBuilder validateFileDetails(StringBuilder errMsg,RequestFile requestFile);

    /**
     * validate the file name
     * @param fileName
     * @return
     */
    protected abstract String validateFileName(String fileName);

    /**
     * return the current CSYNC_UPDATE_WORKFLOW.UPDATE_WORKFLOW_ID
     * @return
     */
    protected abstract WorkflowEnum accessWorkflow();

    /**
     * return the current file name"s format ,such as: csync_policy_yyyyMMdd_HHmmss_count.txt
     * @return
     */
    protected abstract String accessFileNameFormat();

    /**
     * return the subclass"s spring bean name
     * @return
     */
    protected abstract String accessBeanName();

以上抽象方法就類似我們常說的鉤子函數(shù)，由子類實現(xiàn)即可。類圖如下圖所示：

在AbstractRequestValidation抽象類中有個抽象方法validateFileDetails，校驗的是文件的明細內容中的相應業(yè)務規(guī)則，此為核心校驗， 較為復雜，而且針對每個業(yè)務流程，其校驗邏輯相差較大，在此處，利用了責任鏈模式進行處理。

Validator為校驗器的父接口，包含兩個泛型參數(shù)(即：)，其實現(xiàn)類可以方便的轉換需要校驗的文件明細。

String doValidate(R detail, F file, ValidatorChain chain) throws BusinessValidationException;

該方法含有一個ValidatorChain參數(shù)，就自然而然的為該校驗器形成一個鏈條提供便利條件。

ValidatorChain為校驗器鏈，含有兩個接口方法：

String doValidate(T requestDetail, F requestFile) throws BusinessValidationException;

ValidatorChain addValidator(Validator validator, WorkflowEnum workflowId);

該處有一個addValidator方法，為ValidatorChain對象添加校驗器的方法，返回本身。對應于每個業(yè)務流程需要哪些校驗器就在此實現(xiàn)即可（即AbstractRequestValidation的子類方法validateFileDetails）。

類圖如下圖所示：

如果單單從上面的校驗器實現(xiàn)上來看，如果需要增加一個校驗器，就需要在AbstractRequestValidation的子類方法validateFileDetails中添加，然后進行相應的校驗操作。這樣就會非常的麻煩，沒有做到真正的解耦。 此時，策略模式就發(fā)揮到了可以動態(tài)選擇某種校驗策略的作用（Validator的實現(xiàn)類就是一個具體的校驗策略）。

AbstractValidatorHandler抽象類持有FileDetailValidatorChain類的對象，并且實現(xiàn)累Spring的一個接口ApplicationListener（是為了Spring容器啟動完成的時候自動把相應的校驗器加入到校驗器鏈中）。 核心就是WorkflowEnum這個策略枚舉的作用，在子類可以動態(tài)的取得相應的校驗器對象。

根據(jù)子類提供需要的校驗器所在的包名列表和不需要的校驗器列表，動態(tài)配置出需要的校驗器鏈表。核心實現(xiàn)邏輯如下：

private void addValidators() {
    List> validators = getValidators();

    validators.forEach((validator) -> {
        String simpleName = validator.getSimpleName();
        String beanName = simpleName.substring(0, 1).toLowerCase() + simpleName.substring(1);

        LOGGER.info("Added validator:{},spring bean name is:{}",simpleName,beanName);

        Validator validatorInstance = ApplicationUtil.getApplicationContext().getBean(beanName,validator);

        fileDetailValidatorChain.addValidator(validatorInstance,getWorkflowId());

    });
}

具體實現(xiàn)可以參考github代碼即可。

該類含有以下幾個抽象方法：

protected abstract WorkflowEnum getWorkflowId();
/**
 * the package need to be added the validators
 * @return
 */
protected abstract Set getBasePackages();

/**
 * the classes need to be excluded
 * @return
 */
protected abstract Set excludeClasses();

事例代碼地址：https://github.com/landy8530/...