代码重构记录

旧代码复用率低，导致重复代码多，耦合严重，往往修改一个参数就需要修改多个接口，一番挣扎之后决定对旧的代码进行重构

先贴出一段旧代码,因为之前忘了在本地编辑器截图,还好在git上能查看历史代码
一次代码重构记录 - 图1

可以看到框住的这一部分代码，都是一些对参数的校验代码或者是业务的校验代码，这部分的代码不适合放在具体的业务实现类中，这会导致这个方法”责任”过重，也违反了单一职责，针对这一部分的代码，使用了AOP进行处理，将校验（验证）的代码都放在了切面中，解耦的同时也能够更加灵活地进行控制。

  1. // 定义了一个Aspect去实现
  2. public class DataValidateAspect extends Result {
  3.     @Pointcut(value = "execution(...)")
  4.     public void validatePointCut() {
  5.     }
  7.     @Around("validatePointCut()")
  8.     public Object validateBeforeCheck(ProceedingJoinPoint joinPoint) throws Throwable {
  9.         MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
  10.         String[] paramsName = methodSignature.getParameterNames();
  11.         // 获取参数下标
  12.         int request = ArrayUtils.indexOf(paramsName, "xxx");
  13.         int check = ArrayUtils.indexOf(paramsName, "xxx");
  15.         Object[] args = joinPoint.getArgs();
  16.         if (args[request] instanceof UserRequest) {
  17.             ... // 忽略一些代码
  18.             // 进行一系列的校验    
  19.             if (phoneNumber != null) {
  20.                 phoneNumber = filterPhone(phoneNumber);
  21.                 userRequest.setPhoneNumber(phoneNumber);
  22.                 // 校验手机号
  23.                 if (phoneNumber == null) {
  24.                     log.info("phoneNumber verification failed...");
  25.                     return result(StatusCode.PARAM_WRONG);
  26.                 }
  27.             }
  29.             // 校验身份证
  30.             if (!checkIdCard(idCardNo)) {
  31.                 log.info("idCard verification failed...");
  32.                 return result(StatusCode.PARAM_WRONG);
  33.             }
  35.             userName = checkName(userName);
  36.             // 校验姓名
  37.             if (userName == null) {
  38.                 log.info("username verification failed...");
  39.                 return result(StatusCode.PARAM_WRONG);
  40.             }
  41.             ... // 忽略后续的校验代码
  42.         }
  44.         return joinPoint.proceed(); // 
  45.     }
  46. }

以上就完成了将校验从业务代码中解耦出来，并且改切面还可以配置不同的切点，对不同的实现业务进行校验的步骤。修改校验规则的时候，也只需要对切面的代码进行更改就可以影响到多个实现类。

继续贴出后面的一段代码：

一次代码重构记录 - 图2

对外暴露多个接口（Controller），但多个接口都调用了同一个Service，通过code不同去实现逻辑，如上图所示，switch…case -> todo 的方式，这样当接口数目增多，分支多了之后，一个方法的代码就是几百行，显然很不合理。因为前面的校验代码已经交给AOP去处理了，后面的逻辑代码可以进一步拆分为多个实现类去完成，这里又因为每个实现有相似的规则，于是想到了使用模板方法（设计模式）去重构。

  1. @Slf4j
  2. public abstract class AbstractCheckData extends Result {
  4.     @Autowired
  5.     protected BusinessMapper businessMapper;
  7.     @Autowired
  8.     protected UserListService userListService;
  10.     @Autowired
  11.     protected RequestDataMapper requestDataMapper;
  13.     @Autowired
  14.     protected TransHistoryService transHistoryService;
  16.     /**
  17.      * 实现模板（Template method）
  18.      *
  19.      * @param userRequest
  20.      * @param checkType
  21.      * @return
  22.      */
  23.     public final String checkData(UserRequest userRequest, String checkType) {
  24.         // 1. 查询历史记录实体封装
  25.         RequestDataHistory requestDataHistory = createDataHistory(userRequest, checkType);
  26.         // 2. 商户信息查询
  27.         Business business = getBusiness(userRequest, checkType);
  28.         // 3. 用户信息查询
  29.         UserList userList = getUserList(userRequest);
  30.         // 4. 各项的todo
  31.         return check(userRequest, requestDataHistory, business, userList);
  32.     }
  34.     ...
  36.     /**
  37.      * 交给子类实现的具体方法
  38.      *
  39.      * @return
  40.      */
  41.     protected abstract String check(UserRequest userRequest, RequestDataHistory requestDataHistory, Business findBusiness, UserList userList);
  42. }
  44. // 子类
  45. @Service
  46. public class CheckMultiImpl extends AbstractCheckData {
  47.     @Override
  48.     protected String check(UserRequest userRequest, RequestDataHistory requestDataHistory, Business findBusiness, UserList userList) {
  49.         ... // 具体逻辑实现
  50.     }
  51. }
  52. ...
  1. // 接口
  2. public interface CheckDataService {
  4.     /**
  5.      * 相关信息查询，根据 checkType 判断
  6.      *
  7.      * @param userRequest
  8.      * @param checkType
  9.      * @return
  10.      */
  11.     String checkData(UserRequest userRequest, String checkType);
  12. }
  14. @Service
  15. public class CheckDataServiceImpl<R> implements CheckDataService {
  17.     @Override
  18.     public String checkData(UserRequest userRequest, String checkType) {
  19.         // 表驱动代替if + 多态实现
  20.         Map<String, AbstractCheckData> checkDataMap = getCheckMap();
  21.         AbstractCheckData checkSub = checkDataMap.get(checkType);
  23.         return checkSub.checkData(userRequest, checkType);
  24.     }
  26.     /**
  27.      * 映射表
  28.      * checkType -> impl
  29.      *
  30.      * @return
  31.      */
  32.     private Map<String, AbstractCheckData> getCheckMap() {
  33.         Map<String, AbstractCheckData> map = new HashMap<>();
  35.         map.put("1001", checkMulti);
  36.         map.put("1002", checkBlack);
  37.         map.put("1003", checkGray);
  38.         map.put("1004", checkActivity);
  39.         map.put("1005", checkRepaymentTime);
  40.         map.put("1006", checkRepaymentAmount);
  41.         map.put("1007", checkRepaymentIntensity);
  43.         return map;
  44.     }
  45. }

重构之后，使用了模板方法模式，让步骤成为一个模板，定义一个抽象的父类，将公共的模板方法在父类中进行实现，代码清爽了不少，也更容易拓展，修改，可读性也提高了。缺点是类文件会增加（一个接口独立一个实现类）。