在日常业务迭代工作中，我们经常会遇到这样一种需求：基于现有的稳定业务进行其他业务线的拓展，以此来满足产品以及市场的拓展需求。
这里有两个重点：
- 已存在业务相对固定的稳定流程业务
- 基于第一点进行相似业务的拓展
在这样的场景下要是代码写的功利一点，很容易就会形成下面这样的代码：
if (业务A) {}
else if (业务B) {}
else if (业务C) {}
else if (业务D) {}
else if (业务E) {}
...
事实上，我在公司项目源码中看到的业务代码也是这样。
所以，为了后续再次拓展相似业务的开发方便，我通过模板模式对这块代码进行了重构。
1. 业务背景
此次进行重构的业务代码主要的作用是基于不同厂商提供的数据文件，首先进行文件格式校验，然后进行解析，随后保存核心数据，最后看情况进行额外的业务处理。
原来的业务代码中对文件格式校验、解析数据文件、以及额外业务处理进行了三段冗长的 **if-else ** 判断，观之令人身心一震，叹为观止，心服口服，五体投地。
2. 重构策略
上文已经说过，我是基于模板模式进行重构的。
其实这个重构的想法最初还是起源于掘金上的一篇文章——《消除代码中的 if-else/switch-case》，重构策略也是参照这篇文章中的思路，感谢大佬。
2.1 抽象模板业务接口
基于该业务的背景，我抽象出一个通用接口，覆盖了此类业务所有的功能。
public interface AnalysisDataFileInterface {
/**
* 前置方法：检查数据文件格式
*
* @return boolean
*/
boolean preValidFile();
/**
* 核心业务方法：执行解析数据文件
*/
void doAnalysis();
/**
* 是否需要执行额外业务的标识
*
* @return boolean
*/
boolean doExtra();
/**
* 额外业务
*/
void extraBusiness();
}
值得一提的是，经典的模板模式是通过抽象类来实现的，模板方法设置为 final ，然后其他需要子类来实现的方法设置为抽象方法，但事实上我们在项目中使用模板模式可以更灵活一些，像我就使用接口来实现。
通过接口来实现模板模式有两个好处：
- 规避了抽象类实现模式中，由于 Java 单继承导致的限制
- JDK1.8 以后接口可以有默认实现，具体业务类不需要实现接口中的所有方法
2.2 具体业务类
定义好相似业务的抽象接口之后，就可以制定具体的业务类了，在本案例中，我拓展了两个具体业务类。
@Service("A")
public class ABusiness implements AnalysisDataFileInterface {
private static final Logger logger = LoggerFactory.getLogger(ABusiness.class);
/**
* 前置方法：检查数据文件格式
*
* @return boolean
*/
@Override
public boolean preValidFile() {
logger.info("开始执行 A业务 的数据文件的前置校验方法");
return true;
}
/**
* 核心业务方法：执行解析数据文件
*/
@Override
public void doAnalysis() {
logger.info("开始执行 A业务 的核心业务");
}
/**
* 是否需要执行额外业务的标识
*
* @return boolean
*/
@Override
public boolean doExtra() {
return true;
}
/**
* 额外业务
*/
@Override
public void extraBusiness() {
logger.info("开始执行 A业务 的额外业务");
}
}
@Service("B")
public class BBusiness implements AnalysisDataFileInterface {
private static final Logger logger = LoggerFactory.getLogger(BBusiness.class);
/**
* 前置方法：检查数据文件格式
*
* @return boolean
*/
@Override
public boolean preValidFile() {
logger.info("开始执行 B业务 的数据文件的前置校验方法");
return true;
}
/**
* 核心业务方法：执行解析数据文件
*/
@Override
public void doAnalysis() {
logger.info("开始执行 B业务 的核心业务");
}
/**
* 是否需要执行额外业务的标识
*
* @return boolean
*/
@Override
public boolean doExtra() {
return false;
}
/**
* 额外业务
*/
@Override
public void extraBusiness() {
logger.info("开始执行 B业务 的额外业务");
}
}
在具体业务类中我只是简单地输出了几行日志，需要注意的是，A业务需要执行额外业务，B业务不需要执行额外业务，这是由 doExtra() 方法来决定的。
同时，由于本案例是在 SpringBoot 环境中启动的，所以具体的业务类通过 @Service 注解注入到 Spring 容器中，Bean 的名称分别为 A 和 B。
2.3 模板方法
在完成了具体业务类的通用接口化改造之后，就到了服务层的改造阶段了。前面也说到了，这是一个相似的业务逻辑，它分为三个步骤：
- 文件格式校验
- 解析数据文件，核心业务逻辑，保存核心数据
- 根据实际情况进行额外的业务处理
所以，对于这样固定的业务，在进行拓展时，我使用了模板模式进行改造，改造后的控制层代码如下：
@RestController
public class BusinessController {
/** 注入所有实现了 AnalysisDataFileInterface 接口的具体业务类 */
@Resource
private Map<String, AnalysisDataFileInterface> businessMap;
/**
* 根据传入的 businessType 参数选择合适的具体业务类
* @param businessType
* @return
*/
private AnalysisDataFileInterface chooseBusiness(String businessType) {
return businessMap.get(businessType);
}
/**
* 对外提供的业务接口
* @param businessType
* @return
*/
@GetMapping("/doBusiness")
public String doBusiness(String businessType) {
// 1. 根据传入的参数选择指定业务类
AnalysisDataFileInterface business = this.chooseBusiness(businessType);
if (business == null) {
return "failed: no such business";
}
// 2. 校验文件格式
if (!business.preValidFile()) {
return "failed：wrong file";
}
// 3. 执行核心业务
business.doAnalysis();
// 4. 执行额外业务
if (business.doExtra()) {
business.extraBusiness();
}
return "success";
}
}
理论上来说，业务逻辑代码应该下沉到服务层，这里放在控制层只是为了方便展示。然后我将对外接口改造成了一个模板方法，通过四个核心通用步骤来覆盖所有类似的业务：
- 根据传入的参数选择指定业务类
- 校验文件格式
- 执行核心业务
- 执行额外业务
第2~4个步骤与上述的三个相似业务是对应的，而在改造后的模板方法中，只是多了第一步——根据传入的参数选择指定业务类。通过注入一个 value 为 AnalysisDataFileInterface 接口的 Map，注入了在 Spring 容器中所有存在的实现该接口的具体业务类，然后再根据传入的 businessType 选择每次请求对应的业务类，执行模板方法中的指定业务。
在改造完成以后，如果需要再进行业务拓展，后端只需要新建一个实现了 AnalysisDataFileInterface 接口的类，在这个业务类中编写特定的业务逻辑就可以，doBusiness 接口的核心业务代码完全不用做任何修改就能够适配。
否则，如果在改造之前，则需要在三处 if-else 中新增对新业务的 else 判断代码块，然后调用对应的业务代码，既增加了方法的复杂度，也降低了其可读性，增加维护成本。
3. 模板模式
3.1 定义
模板模式（Template Method Design Pattern，全称模板方法模式），是指：定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
模板模式由两种角色构成：
- 基本方法：也叫做基本操作，是由子类实现的方法，并且在模板方法被调用。即上述重构代码中实现了 AnalysisDataFileInterface 接口的类。
- 模板方法：可以有一个或几个，一般是一个具体方法，也就是一个框架，实现对基本方法的调度，完成固定的逻辑。即上述重构代码中的控制层方法。
3.2 优点
封装不变部分，扩展可变部分。把认为是不变部分的算法封装到父类实现，而可变部分的则可以通过继承来继续扩展。
提取公共部分代码，便于维护
行为由父类控制，子类实现。基本方法是由子类实现的，因此子类可以通过扩展的方式增加相应的功能，符合开闭原则。
3.3 缺点
按照我们的设计习惯，抽象类负责声明最抽象、最一般的事物属性和方法，实现类完成具体的事物属性和方法。但是模板方法模式却颠倒了，抽象类定义了部分抽象方法，由子类实现，子类执行的结果影响了父类的结果，也就是子类对父类产生了影响，这在复杂的项目中，会带来代码阅读的难度，而且也会让新手产生不适感。
3.4 使用场景
多个子类有公有的方法，并且逻辑基本相同时。
重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。
重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数约束其行为
4. 参考
最后，本文收录于个人语雀知识库: 我所理解的后端技术，欢迎来访。
文档信息
- 本文作者：Planeswalker23
- 本文链接：https://planeswalker23.github.io/2021/09/08/%E6%88%91%E6%89%80%E7%90%86%E8%A7%A3%E7%9A%84%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E7%B3%BB%E5%88%97-%E7%AC%AC13%E7%AF%87-%E5%9F%BA%E4%BA%8E%E6%A8%A1%E6%9D%BF%E6%A8%A1%E5%BC%8F%E9%87%8D%E6%9E%84-if-else-%E4%BB%A3%E7%A0%81%E5%9D%97/
- 版权声明：本作品系原创，作者保留所有权利，未经作者允许，禁止转载和演绎。