技巧|业务代码简单重构记录手札

前言

业务开发过程中不知道有没有遇到过这样的一种情况,随着业务复杂度上升发现在某个XxxServiceImpl业务具体实现中,某几个接口在业务逻辑实现上存在关联比较大,异常繁琐,代码量很大,复杂,每次打开这个实现类追查具体逻辑问题,发现头痛不已,在各个private定义私有方法中相互跳动,有可能多个业务有关联接口需要的用同一个定义的静态变量,或者私有方法,维护起来异常头疼.本文针对这种情况提出按照具体业务分别对应不同的handler中,公共方法,静态常量维护在公共抽象类中,有点像策略模式的思想;

• Spring
• IDEA
• MacOs/Windows

业务场景

如果目前有这样的一个业务场景:

1.外部接口调用PAAS服务一笔案件,案件的数据包含比较复杂数据信息,比如案件基本信息,证据等信息;需要将数据保存到本地DB;
2.案件创建成功之后需要从OSS拉取文件信息,然后将文件按照三方接口的需要将数据传输至对方文件服务器上;
3.文件上传成功之后,调用三方接口,按照三方的接口参数需求进行整合,然后调用三方接口进行创建;

综合分析一下,这里步骤的第一步和最后一步都需要的很大的数据业务整合,频繁的操作DB,数据整合与拼接会有很大代码量,如果全部放在同一个类文件中,维护较为困难;

代码结构

先定义一个抽象类ArbitrationCaseHandlerAdapter抽象类中定义具体的业务需要的实现各个方法,由具体Handler处理各自不同的业务;

这样在每一个handler中具体处理各自业务,需要共同使用的方法,静态常量可以定义在抽象类ArbitrationCaseHandlerAdapter中,这样每次修改具体业务代码进行功能扩展,就在具体的handler中进行,这样比较容易追溯与修改;

1.定义ArbitrationCaseHandlerAdapter抽象类,抽象类就类似于"模板"的作用,为了不让具体的handler全部实现所有方法,在抽象类中直接定义具体方法,但是逻辑均不在其中实现,抽象类无法进行实例化,依赖派生类进行具体实例,所以所有具体实现,由handler覆写.

public abstract class ArbitrationCaseHandlerAdapter {
  /**
   * 创建本地案件
   * @param caseInfo
   * @param baseInfo
   * @param userUid
   * @return
   */
  public String createArbcaseByRequest(String param) { return null;} 

  /**
   * 上传oss文件
   * @param caseId
   * @return
   */
  public boolean uploadFileCreator(String param) { return false; }

  /**
   * 调用三方接口远程创建案件
   */
  public Long remoteCreate(String param) {return null;}
}

2.定义CreateArbCaseHandler处理本地案件信息创建的具体逻辑;

@Component
@Qualifier("createArbCaseHandler")
public class CreateArbCaseHandler extends ArbitrationCaseHandlerAdapter {
  @Override
  public String createArbcaseByRequest(String param) {
    //TODO 具体逻辑代码
  }
}

3.定义UploadFileHandler处理案件文件信息上传至OSS或者三方机构;

@Component
@Qualifier("uploadFileHandler")
public class UploadFileHandler extends ArbitrationCaseHandlerAdapter {
  @Override
  public boolean uploadFileCreator(String param) {
  //TODO 具体逻辑代码  
  }
}

4.定义RemoteCreateHandler处理三方案件创建的具体逻辑;

@Component
@Qualifier("remoteCreateHandler")
public class RemoteCreateHandler extends ArbitrationCaseHandlerAdapter { 
  @Override
  public void remoteCreate(Long caseId, boolean upload) {
		//TODO 具体逻辑代码
  }
}

具体引用使用地方,直接引用使用Spring依赖注入即可,以后再次修改直接进入具体的handler中处理,修改.这样XxxServiceImpl中的结构变的比较清爽;

public class ArbitrationServiceImpl implements ArbitrationService {
  @Autowired
  @Qualifier("createArbCaseHandler")
  private ArbitrationCaseHandler createArbCaseHandler;

  @Autowired
  @Qualifier("uploadFileHandler")
  private ArbitrationCaseHandler uploadFileHandler;

  @Autowired
  @Qualifier("remoteCreateHandler")
  private ArbitrationCaseHandler remoteCreateHandler;
}

这种情况对于业务开发,应该很常用,代码结构上来讲比较整洁一点,方便追具体的业务问题,方便功能的扩展,功能相对简单,只是说明这样一种处理思路.

结语

具体业务应该具体分析,这个是工作中发现几个服务中都可以使用逻辑,这个也比较简单,之前也看到别人代码,全部处理在一个Service中,最终发现代码量比较大,很多各个流程夹杂在一起private方法,结构看起来很麻烦,所以整理一下手札方便记录,以后有更好的方法,再做修改.

关于我

Hello,我是球小爷,热爱生活,求学七年,工作三载,而今已快入而立之年,如果您觉得对您有帮助那就一切都有价值,赠人玫瑰,手有余香❤️. 最后把我最真挚的祝福送给您及其家人,愿众生一生喜悦,一世安康!

附录

• 技巧|结合业务一些常用开发技巧记录手札
• 技巧|Mybatis批量操作常见方式总结
• 技巧|简单重构Mybatis基本CRUD的使用
• 技巧|业务代码简单重构记录手札
• 技巧|腾讯云Mysql简单配置记录手札
• 技巧|JAVA中时间操作