记一次代码重构

最近在编写Service层的时候，出现了这样的问题：

由于对数据合法性的要求比较高，光靠外键显然不能胜任，因此我全面抛弃外键，在Service层用大量代码校验数据的合法性。

于是就出现了这样的代码：

 public Map editXXX(Entity entity){

    Map result = new Map<>;
    boolean flag = true;
    if(entity.getparam1() is invaild){
        flag = false;
        logger.log;
        result.put("msg","param1 is invaild");
    }
    ...(param2)

    result.put("result",flag);
    if(!flag){
        return result;
    }
    
    ...mapper.Update(entity);
    logger.log;
    result.put("msg","success");

    return result;
}

这里具体检测是否有效的代码比较复杂，例如update方法的id肯定不能是null，积分明细的uid必须在user表里查得到。

这样写着写着，写了五个Service之后开始觉得迷茫，懵逼，姜硬，可读性、可维护性差，耦合度高。

于是萌生出重构的想法，某人一语惊醒我把这些if独立成一个方法。

直接独立肯定不行，我Service是面向接口写的，难道在接口中先定义好这样的check方法？

本来想将它抽出来做切面，但是毕竟这是业务逻辑的核心代码，不是日志和性能这些边缘功能，AOP印象里是改变不了方法某个局部变量的值的……

看了一眼之前整合shiro的util包，决定在util包下建一个subpackage叫checker，然后定义baseChecker类，里面定义几个常用方法。

其他具体的实体检查器就继承它，然后将这些checker对象注入Service类进行调用即可。

在定义baseChecker类的时候，由于对Java基础语法不够熟悉，我写出了这样的代码：

public class baseChecker {

    public boolean checkNull(Object object,boolean flag){
        return flag;
    };
}

然后我发现这里需要使用的是泛型，而不是Object，而且泛型声明应该放在类里，正确的写法应该是：

public class baseChecker<T> {

    public boolean checkNull(T t,boolean flag){
        return flag;
    };
}

然后子类这么写：

public class userChecker extends baseChecker {
    @Override
    public boolean checkNull(Object o , boolean flag) {
        return flag;
    }
}