设计模式实战

最新推荐文章于 2024-07-31 09:59:06 发布

dray_

最新推荐文章于 2024-07-31 09:59:06 发布

阅读量720

点赞数 1

分类专栏：设计模式文章标签：设计模式 java

本文链接：https://blog.csdn.net/tushuping/article/details/115408216

版权

设计模式专栏收录该内容

2 篇文章 0 订阅

订阅专栏

使用设计模式消除if/else

设计模式概述

设计模式其实是一个比较抽象的东西，它就像武侠小说里的武功秘笈，比如单例模式是一阳指，策略模式是独孤九剑，模板方法模式是无相神功……但即使我们对这些武功秘籍倒背如流，在实战的时候往往还是被一拳擂倒，那为什么在人人如龙的时代（武功秘笈不要钱）,有的人降龙十八掌就能打出龙，有的人打出虫呢，下面我们根据一个实例一步步去掌握这些武功秘笈的诀窍

业务场景

手上接到一个项目，需要有动态表功能，什么意思呢，正常比如我们有一个user表，可能有name,age,phoneNum等字段，这些字段都是我们在软件创建初期就设计好的，在编码里面有个User类与表一一映射，一旦我们的表需要新增一个字段sex,那我们需要修改表结构，并修改代码。而我们现在的需求直接在管理界面动态修改表的字段，这样无需修改表和代码就能做到表字段的动态扩展，甚至我们能动态扩展新的表

场景拆分

我们需要实现上述功能，肯定需要定义表的属性，字段，字段的类型，长度，是否唯一，是否是可编辑，是否是展示字段，是否是搜索字段，是否是排序字段，是否允许空，是否是导入字段等等，表定义比较简单，但是表定义的数据怎么存储呢？如果按字段key,value等方式存储，查询时我们要列转行，分页排序等功能就非常麻烦了，由于我们的字段是动态的，所以数据是可变的，这种格式是不是很熟悉，json，没错，对nosql比较熟悉的人，脑子里肯定已经跳出来，Bson->mongodb，所以我们最终决定固定数据存储mysql,动态数据存储mongodb

问题产生

一直到这里其实还没讲到和设计模式有半毛钱关系，客观莫急，听我慢慢道来，mysql数据库字段属性固定的属性，比如是否唯一，是否为空，字段类型等等，他帮我们做了很多的校验，但是我们现在属性是动态的，字段就需要我们去做校验了，比如我现在要新增一条user记录，我需要做哪些内容呢？

{
    "name": "张芷",
    "age": "17",
    "tableName": "user"
}

上述内容为新增一条记录的前端传过来的数据

当前表是否存在
数据字段是否为表里的字段
字段类型是否匹配
非空字段是否不为空

如果是修改呢？

当前表是否存在
数据字段是否为表里的字段
字段类型是否匹配
非空字段是否不为空
字段是否是可编辑字段

如果是导入呢？查询呢？
不同的操作需要有不同的校验，校验内容获取相同或许不同，或者有顺序或者无序，如每个操作前加这样的校验会极其丑陋且大量重复代码，各种if/else满天飞，还没到具体的业务逻辑就已经晕了

如何解决

我们既然已经掌握了大量秘笈，要学会见招拆招
首先我们这么多校验需要在每个操作前去做，它不属于核心代码，我们不能让方法自己去做，但是如果它不做，谁去呢？代理啊，西门庆要去找潘金莲鼓掌，他不能直接冲上去啊，那样是违法的，所以他得先问问金莲的意愿，所以他找了代理->王婆，王婆也是女人，女人了解女人啊，所以她在里面穿针引线，帮西门庆解决了很多前期问题，等王婆搭好桥梁，他就直接过去鼓掌了，所以我们首先得找个代理，由此，我们的第一个设计模式，代理模式呼之欲出——

代理模式

代理又分静态代理和动态代理，明显我们各种校验的是动态的，所以我们这里需要使用到动态代理
spring的aop为我们提供了很好的实践，我们直接使用就好了。
首先我们需要一个注解，去标记哪些类需要做校验

@Target({ ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ModelCheck {

    FiledCheckEnum[] value() default {};

}

其中FiledCheckEnum是一个枚举类，列举了我们需要校验的类型

    //检查字段是否存在
    CHECK_FILED_EXIST(0,"存在校验"),

    CHECK_FILED_NULL(1,"非空校验"),

    CHECK_FILED_SEARCH(2,"搜索校验"),

    CHECK_FILED_EDIT(3,"编辑校验"),

    CHECK_FILED_IMPORT(4,"导入校验"),

    CHECK_FILED_SORT(5,"排序校验"),

    CHECK_FILED_TYPE(6,"类型校验"),

我们一个操作需要有多重的校验，所以用一个数组将需要进行的校验操作进行组合

    @ApiOperation("添加ci项")
    @PostMapping("/add")
    @ModelCheck(value = {FiledCheckEnum.CHECK_FILED_EXIST,FiledCheckEnum.CHECK_FILED_NULL})
    public ApiResponse add(
            @ApiParam(required = true, name = "params", value = "添加参数")
            @RequestBody Map<String, Object> params) {
        ciItemService.addCiItem(params);
        return new ApiResponse<>().success();
    }

然后我们需要定义一个切面去拦截这些方法和进行具体操作

@Aspect
@Component
public class ModelCheckAspect {


    @Autowired
    private TablesService tablesService;

    @Autowired
    private CustomizeConfig customizeConfig;

    @Pointcut("@annotation(com.dr.cmdb.application.annotation.ModelCheck)")
    public void modelCheckAspect() {
    }

    @Before("modelCheckAspect()")
    public void doBefore(JoinPoint joinPoint) {
        //拿到被注解的方法签名
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        //拿到被注解的方法
        Method method = signature.getMethod();
        Method targetMethod = AopUtils.getMostSpecificMethod(method, joinPoint.getTarget().getClass());
        //拿到被注解类的参数
        Object[] arguments = joinPoint.getArgs();
        if (null == arguments || arguments.length <= 0) {
            throw new BizException(BaseCode.PARAM_ERROR);
        }
        //获取当前方法注解里的参数
        ModelCheck modelCheck = AnnotationUtils.findAnnotation(targetMethod, ModelCheck.class);
        //先匹配方法名
        Map<String, Object> argument = (Map<String, Object>) arguments[0];
        List<TableModelsDto> tableCols = tablesService.getTableCols((String) argument.get(customizeConfig.getCiTableName()));
        if (CollectionUtils.isEmpty(tableCols)) {
            throw new BizException(BaseCode.PARAM_ERROR);
        }
        //构建校验参数
        FiledCheckDto build = FiledCheckDto.builder()
                .argument(argument)
                .tableCols(tableCols)
                .checkEnums(Arrays.asList(modelCheck.value()))
                .ciTableName(customizeConfig.getCiTableName())
                .build();
         //执行校验责任链
        FiledCheckHandlerFactory.processHandler(build);
    }

具体操作如代码所示，拦截方法，获取方法的参数，获取注解里面的参数
最后调用校验执行

FiledCheckHandlerFactory.processHandler(build);

大家可以先忽略这句，我们继续分析

看到上面这个图有没有福至心灵，链……链……对，

责任链模式

我们先定义我们的校验责任链。然后传递我们需要校验的类型去做匹配，不同于普通的责任链只匹配一个节点就退出，我们需要遍历完整个责任链，我们的校验类型是动态的，所以我们需要把我们需要做的校验都做完，我们一般称这种为变种责任链，降龙十八掌你会了，是不是可以考虑降龙三十六掌也是可以的啊

先定义责任链的抽象类

@Data
public abstract class FiledCheckHandler {

    protected FiledCheckHandler nextHandler = null;

    public abstract FiledCheckEnum getType();

    /**
     * 检测字段是否符合规范
     */
    public void handler(FiledCheckDto filedCheckDto) {
        //匹配到该类型
        if (filedCheckDto.getCheckEnums().contains(getType())) {
            checkHandler(filedCheckDto);
        }
        if (null == nextHandler) {
            return;
        }
        nextHandler.handler(filedCheckDto);
    }


    /**
     * 子类具体校验
     *
     * @param filedCheckDto
     */
    public abstract void checkHandler(FiledCheckDto filedCheckDto);
}

代码里面有两个方法，getType，checkHandler
getType主要让子类告我们它是做哪种校验的
checkHandler是子类具体的校验操作

@Order(3)
@Component
@Slf4j
public class FiledCheckEditHandler extends FiledCheckHandler {

    @Override
    public FiledCheckEnum getType() {
        return FiledCheckEnum.CHECK_FILED_EDIT;
    }

    /**
     * 检测字段是否符合规范
     *
     * @param filedCheckDto
     */
    @Override
    public void checkHandler(FiledCheckDto filedCheckDto) {
        Map<String, Object> argument = filedCheckDto.getArgument();
        List<TableModelsDto> tableCols = filedCheckDto.getTableCols();
        List<String> collect = tableCols.stream().filter(e -> !e.getEditFlag()).map(TableModelsDto::getModelName).collect(Collectors.toList());
        argument.forEach(
                (k, v) -> {
                    if (collect.contains(k)) {
                        LoggerUtil.error(log,"字段不可编辑:{}", k);
                        throw new BizException(BizCode.FIELD_NOT_EXIST.getCode(), "字段不可编辑:" + k);
                    }
                }
        );
    }

}

这种父类定义方法，子类去实现，然后父类调用的设计模式就是

模板方法模式

大家也注意到这个细节@Order(3)，由于我们的参数校验有顺序的，所以我们在构建责任链的时候需要按照我们设定的顺序来
到此为止，我们已经有我们的各种检验方法了，那么我们怎么把我们的检验方法创建出来呢，造，造出来，没错，下一个模式脱口而出

工厂模式

spring容器在初始化过程中给我们预留了很多的钩子，我们可以利用这个特性将我们的校验责任链初始化，具体逻辑如下：

@Component
public class FiledCheckHandlerFactory implements CommandLineRunner, ApplicationContextAware {
    private volatile ApplicationContext applicationContext;


    private static FiledCheckHandler handlers;


    /**
     * 拼接变种责任链
     * @param args
     */
    @Override
    public void run(String... args) {
        Collection<FiledCheckHandler> checkHandlers = this.applicationContext.getBeansOfType(FiledCheckHandler.class).values();
        List<FiledCheckHandler> list = Lists.newArrayList(checkHandlers);
        Collections.sort(list, AnnotationAwareOrderComparator.INSTANCE);
        for (int i = 0; i < list.size() - 1; i++) {
            list.get(i).setNextHandler(list.get(i + 1));
        }
        handlers = list.get(0);
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }

    /**
     * 执行方法校验
     * @param filedCheckDto
     */
    public static void processHandler(FiledCheckDto filedCheckDto) {
        handlers.handler(filedCheckDto);
    }


}

你以为这样就完了么？
看到processHandler方法没，它确实是一个普普通通的静态方法，自己不干事交给别人干，我们可以把它理解为

委托模式

在这些设计模式的架构下，我们就可以很方便的进行校验规则的扩展，如果要新增校验类型，只要继承校验抽象类，实现两个方法就可以了，基本不需要使用if/else了，其实我们在开发过程中都有意无意地使用到了各种设计模式，只是自己没有去深究，但我还是建议大家在代码开发前先进行构思，怎么更方便地去实现自己的业务，说明白点就是抽象化的能力，代码抽象化越高，扩展性越强，我们需要有一种大局观，要先跳出具体的实现，考虑通用性，抽取通用性，公共部分，将我们的武功秘笈融会贯通，这样招式才有威力