项目重构,我是如何优化大量屎一样的 if else 代码的?

简介:   目录:  if else策略模式1、首先抽象业务处理器2、将业务处理器和其支持处理的类型放到一个容器中,java里Map就是最常用的容器之一3、定义不同的处理器4、测试类  前段时间,我将公司系统中的批量审单的功能进行了重构,用到了java的并发编程进行异步化处理,数据库的乐观锁机制处理多线程并发更新数据。  其中批量审单的业务处理涉及到多种任务类型,对应不同的业务方法进行处理,比如转仓,转快递,添加赠品,删除赠品,拆分订单,批量驳回,批量作废等等,其中就用到了策略模式。

  目录:

  if else策略模式1、首先抽象业务处理器2、将业务处理器和其支持处理的类型放到一个容器中,java里Map就是最常用的容器之一3、定义不同的处理器4、测试类

  前段时间,我将公司系统中的批量审单的功能进行了重构,用到了java的并发编程进行异步化处理,数据库的乐观锁机制处理多线程并发更新数据。

  其中批量审单的业务处理涉及到多种任务类型,对应不同的业务方法进行处理,比如转仓,转快递,添加赠品,删除赠品,拆分订单,批量驳回,批量作废等等,其中就用到了策略模式。

  if else

  if ("BATCH_CHANGE_WAREHOUSE".equals(taskType)) {

  //批量转仓逻辑

  } else if ("BATCH_CHANGE_SHIPPING".equals(taskType)) {

  //批量转快递逻辑

  } else if ("BATCH_REPLACE_ORDER_GOODS".equals(taskType)) {

  //批量替换订单商品逻辑

  } else if ("BATCH_DELETE_ORDER_GOODS".equals(taskType)) {

  //批量删除订单商品逻辑

  } else if ("BATCH_ADD_MEMO".equals(taskType)) {

  //批量添加备注逻辑

  } else {

  //任务类型未知

  System.out.println("任务类型无法处理");

  }

  看起来,思路清晰,if,else分支也很清楚,但不觉得代码很臃肿,维护起来麻烦吗

  尤其是其他人来接锅的时候,连看下去的欲望都没有了。这时候你需要用策略模式消除其中的if else,进行一下简单的重构!

  策略模式

  1、首先抽象业务处理器

  public abstract class InspectionSolver {

  public abstract void solve(Long orderId, Long userId);

  public abstract String[] supports();

  }

  2、将业务处理器和其支持处理的类型放到一个容器中,java里Map就是最常用的容器之一

  @Component

  public class InspectionSolverChooser implements ApplicationContextAware {

  private MapchooseMap=new HashMap<>();

  public InspectionSolver choose (String type) {

  return chooseMap.get(type);

  }

  @PostConstruct

  public void register () {

  MapsolverMap=context.getBeansOfType(InspectionSolver.class);

  for (InspectionSolver solver : solverMap.values()) {

  for (String support : solver.supports()) {

  chooseMap.put(support,solver);

  }

  }

  }

  private ApplicationContext context;

  @Override

  public void setApplicationContext (ApplicationContext applicationContext) throws BeansException {

  this .context=applicationContext;

  }

  }

  这里是在应用启动的时候,加载spring容器中所有InspectionSolver类型的处理器,放到InspectionSolverChooser的map容器中。

  注意是InspectionSolver类型,所以定义的二手手机号码拍卖处理器都得继承InspectionSolver

  其次是spring容器中的才能加载,所以定义的处理器都得放到spring容器中(@Component注解不能少)

  3、定义不同的处理器

  @Component

  public class ChangeWarehouseSolver extends InspectionSolver {

  @Override

  public void solve(Long orderId, Long userId) {

  System.out.println("订单"+orderId+"开始进行批量转仓了。。");

  }

  @Override

  public String[] supports() {

  return new String[] {InspectionConstant.INSPECTION_TASK_TYPE_BATCH_CHANGE_WAREHOUSE};

  }

  }

  @Component

  public class ChangeShippingSolver extends InspectionSolver{

  @Override

  public void solve(Long orderId, Long userId) {

  System.out.println("订单"+orderId+"开始进行转快递了。。");

  }

  @Override

  public String[] supports() {

  return new String[] {InspectionConstant.INSPECTION_TASK_TYPE_BATCH_CHANGE_SHIPPING};

  }

  }

  @Component

  public class ReplaceOrderGoodsSolver extends InspectionSolver{

  @Override

  public void solve(Long orderId, Long userId) {

  System.out.println("订单"+orderId+"开始进行替换商品了");

  }

  @Override

  public String[] supports() {

  return new String[]{InspectionConstant.INSPECTION_TASK_TYPE_BATCH_REPLACE_ORDER_GOODS};

  }

  }

  4、测试类

  @RunWith(SpringJUnit4ClassRunner.class)

  @SpringBootTest(classes=Application.class)// 指定spring-boot的启动类

  public class InspectionTest {

  @Autowired

  private InspectionSolverChooser chooser;

  @Test

  public void test() throws Exception{

  //准备数据

  String taskType=InspectionConstant.INSPECTION_TASK_TYPE_BATCH_CHANGE_WAREHOUSE;

  Long orderId=12345L;

  Long userId=123L;

  //获取任务类型对应的solver

  InspectionSolver solver=chooser.choose(taskType);

  if (solver==null) {

  throw new RuntimeException("任务类型暂时无法处理!");

  }

  //调用不同solver的方法进行处理

  solver.solve(orderId,userId);

  }

  }

  在测试类中我消除了可能一长段的if else,从选择器InspectionSolverChooser中根据type的不同取出不同的任务处理器InspectionSolver

  然后调用其solve()方法进行任务处理,不同处理器调用的当然就是不同的solve()方法了,目的达到。

  End

  作者:坚持就是胜利

  来源:

  juejin/post/5d12228de51d45775c73dd1b

目录
相关文章
|
设计模式 算法 Java
设计模式第十五讲:重构 - 改善既有代码的设计(下)
设计模式第十五讲:重构 - 改善既有代码的设计
284 0
|
3月前
|
Java Android开发
Android项目架构设计问题之要提升代码的可读性和管理性如何解决
Android项目架构设计问题之要提升代码的可读性和管理性如何解决
38 0
|
设计模式 算法
重构,避免重构误区
重构,避免重构误区
42 0
|
设计模式 Java 测试技术
设计模式第十五讲:重构 - 改善既有代码的设计(上)
设计模式第十五讲:重构 - 改善既有代码的设计
319 0
|
设计模式
重构·改善既有代码的设计.04之重构手法(下)完结
重构改善既有代码的设计完结篇,汇总了全部的重构手法。看看哪些手法对你的项目能有所帮助…
7407 2
重构·改善既有代码的设计.04之重构手法(下)完结
|
设计模式 测试技术
重构·改善既有代码的设计.02之代码的“坏味道”
之前在《重构·改善既有代码的设计.01》中初步了解了重构的基本前提,基础原则等入门知识。今天我们继续第二更......
206 1
重构·改善既有代码的设计.02之代码的“坏味道”
|
开发者
重构的核心-让代码保持整洁
很久之前团队师兄向我推荐了《重构:改善既有代码的设计》这本书,粗略翻阅看到很多重构的细节技巧,但当时还处于未接触过工程代码,只关注代码功能,不太考虑后期维护的阶段,读起来觉得枯燥无味,几乎没有共鸣,一直没有细细阅读。在工作一年后,终于在师兄的督促下,利用一个月左右的早起时光读完了这本书,收获很多,感谢师兄的督促,感谢这本书陪伴我找回了阅读习惯。把这本书推荐给已经接触了工程代码、工作一年左右的新同学,相信有了一定的经验积累,再结合日常项目实践中遇到的问题,对这本书的内容会有很多自己的思考感悟
40593 4
重构的核心-让代码保持整洁
|
设计模式 程序员 开发者
程序员在开发中必经之路:重构代码
众所周知,程序员在开发过程中接手前人代码,或者接手公司外购项目的代码等情况的时候,都有想要重构代码的冲动,与其这样说,不如说程序员只要是接手不是自己亲自写的代码都想重构!俗话说得好:一百个程序员脑中有一百个编程思维,不同程序员就算是开发相同功能的程序,一定会有不同的实现方式,而且代码格式和实现方式也肯定是不一样的,这样就给程序的代码重构留下了伏笔。
162 1
|
数据库
高质量代码优化!谈谈重构项目中if-else代码的几点建议
本篇文章探讨了代码的重构以及优化,主要针对代码中大量的条件判断if-else语句问题提出了具体的优化建议。介绍了优化if-else语句的几种有效的方法,包括switch,接口interface以及数据库实现对条件语句进行的优化。
172 0
高质量代码优化!谈谈重构项目中if-else代码的几点建议
|
存储 设计模式 架构师
记一次项目重构
本文主要记录,刚刚步入架构师岗位4个月的我,重构项目的一些经历。