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

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

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

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

本校驗(yàn)邏輯主要分為四個(gè)部分：

校驗(yàn)文件名稱（RequestValidator.validateFileInfo）

校驗(yàn)文件內(nèi)容中的概要部分（RequestValidator.validateSummary）

校驗(yàn)文件內(nèi)容中的列名稱（RequestValidator.validateHeaders）

校驗(yàn)文件內(nèi)容中的明細(xì)（RequestValidator.validateDetails）

其實(shí)上面的RequestValidator的實(shí)現(xiàn)邏輯最后都是委托給RequestValidationFacade這個(gè)門面類進(jìn)行相應(yīng)的校驗(yàn)操作。

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

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

RequestDetail及其子類就是workflow對應(yīng)文件的明細(xì)內(nèi)容。

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

workflow為WorkflowEnum.POLICY對應(yīng)文件名為：csync_policy_yyyyMMdd_HHmmss_count.txt

workflow為WorkflowEnum.BOB對應(yīng)文件名為：csync_bob_integration_yyyyMMdd_HHmmss_count.txt

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

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

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

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

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

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

類圖如下：

在具體的校驗(yàn)邏輯中，用到核心設(shè)計(jì)模式便是模版方法模式，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ù)，由子類實(shí)現(xiàn)即可。類圖如下圖所示：

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

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

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

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

ValidatorChain為校驗(yàn)器鏈，含有兩個(gè)接口方法：

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

ValidatorChain addValidator(Validator validator, WorkflowEnum workflowId);

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

類圖如下圖所示：

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

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

根據(jù)子類提供需要的校驗(yàn)器所在的包名列表和不需要的校驗(yàn)器列表，動態(tài)配置出需要的校驗(yàn)器鏈表。核心實(shí)現(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());

    });
}

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

該類含有以下幾個(gè)抽象方法：

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/...