如何运用设计模式改进订单集成系统：以POLICY和BOB类型订单为例

简介：好久没有更新了，主要是因为工作比较忙。最近工作中升级了一个子系统，改善了难以扩展的缺点。主要是利用几种设计模式进行轻微的改造。

一、项目背景

在公司的一个实际项目中，我们需要为第三方公司（以下简称GMG）做系统集成工作，将公司的部分订单数据集成到我们自己公司的平台中。每个订单都有一些共性，但也有自己独特的特点。。经过设计，我目前将订单分为POLICY和BOB两种类型（暂且这么说吧，反正只是一种订单类型，大家可以参考一下）。

在订单数据集成到公司平台之前，需要对订单数据进行一些必要的业务逻辑验证操作，每个订单都有自己的验证逻辑（包括公共验证逻辑）。本节介绍了综合运用设计模式的整个订单集成系统中验证逻辑的架构设计。

2. 验证逻辑

这个验证逻辑主要分为四个部分：

验证文件名 (RequestValidator.validateFileInfo) 验证文件内容中的摘要部分 (RequestValidator.validateSummary) 验证文件内容中的列名 (RequestValidator.validateHeaders) 验证文件内容中的详细信息 (RequestValidator.validateDetails)

事实上，上述RequestValidator的实现逻辑最终都委托给了RequestValidationFacade门面类来进行相应的验证操作。 3. 实现细节 3.1 域介绍

主要分为两个域：RequestFile和RequestDetail。 RequestFile接收一个泛型类型（即RequestFile），这样它的子类就可以自动识别RequestDetail对应的子类。 RequestFile是一个抽象类，定义了以下抽象方法，这些方法由子类实现：

//由子类实现具体的获取文件明细内容
public abstract List getRequestDetails();
//由子类实现具体的获取workflow的值
public abstract WorkflowEnum getProcessWorkFlow();
//由子类实现文件列字段名列表
public abstract String[] getDetailHeaders();