一. 使用场景
业务开发中经常会遇到这种问题, 清楚该业务需求所需的关键步骤, 并且知道其执行顺序, 但是未知其具体的实现细节, 或者说实现细节需要特定的条件才能执行
比如, 去银行办理业务一般要经过以下4个流程:取号、排队、办理具体业务、对银行工作人员进行评分等,其中取号、排队和对银行工作人员进行评分的业务对每个客户是一样的,可以在父类中实现,但是办理具体业务却因人而异,它可能是存款、取款或者转账等,可以延迟到子类中实现
二. 模板方法模式
2.1 模板方法模式介绍
《Head First 设计模式》书中是这么定义模板方法模式的 : 模板方法模式在一个方法中定义一个算法的骨架, 而将一些步骤延迟到子类, 模板方法使得子类可以在不修改算法结构的情况下, 重新定义算法中的某些步骤, 这里算法通俗来说就是业务逻辑, 他的主要作用就是方法的复用和拓展
来看一下模板方法模式的类图
2.2 模板的结构
抽象模板类(AbstractClass): 提供一个类, 并定义模板方法, 此方法一般声明为final, 防止子类覆盖, 模板方法定义了算法的骨架, 主要包括 :
公共方法: 在抽象模板类中执行
抽象方法: 根据业务条件延迟到具体的子类执行
抽象钩子方法: 主要用于某些判断, 在子类中决定
具体类: 可以有很多实现类, 实现抽象模板类中的抽象方法, 他是模板方法中的一个具体步骤, 当模板方法需要执行抽象方法时, 会调用子类的方法
三. 模拟实现
3.1 模拟案例分析
用户登录为例, 一个用户登录功能, 其大概的步骤一般是: 检验参数, 校验用户信息, 根据不同身份的用户填充更具体的登录用户信息, 登录之后组装token等等
在本例中, 需要定义一个用户登录抽象类UserLoginTemplate, 里包含了一个模板方法doLogin(), 该方法中包含了用户登录的每个步骤, 也就是模板方法, 其中校验参数, 检验用户信息, 组装token对于所有用户都是一样的, 所以在抽象类中实现, 但是填充具体的登录用户信息需要根据登录人/或环境决定, 所以在具体的子类中实现, 结构图如下
3.2 具体代码
3.2.1 模板类
/**
* @author canxiusi.yan
* @description UserLoginTemplate 用户登录抽象模板
* @date 2022/2/21 16:44
*/
public abstract class UserLoginTemplate {
private static final Logger log = LoggerFactory.getLogger(UserLoginTemplate.class);
/**
* 登录模板方法, 防止子类继承
*
* @param userLoginRequest
* @return
*/
public final BaseRspVo<UserModel> doLogin(UserLoginRequest userLoginRequest) {
// 前置校验登录传递的参数
preCheckParam(userLoginRequest);
// 校验用户信息(密码/用户状态等)
UserModel userModel = thenCheckUser(userLoginRequest);
// 钩子, 填充当前登录用户的独有信息
if (needFillSpecific()) {
fillSpecific(userModel);
}
// 之后的组装token等等
createToken(userModel);
return BaseRspVo.successInstance(userModel);
}
private void preCheckParam(UserLoginRequest userLoginRequest) {
// 统一校验参数
AssertHelper.notNull(userLoginRequest.getId(), new BusinessException(CommonEnum.PARAM_ERROR, "id不能为空"));
AssertHelper.notNull(userLoginRequest.getName(), new BusinessException(CommonEnum.PARAM_ERROR, "name不能为空"));
AssertHelper.notNull(userLoginRequest.getValidateCode(), new BusinessException(CommonEnum.PARAM_ERROR, "验证码不能为空"));
log.info("参数校验通过:{}", userLoginRequest);
}
private UserModel thenCheckUser(UserLoginRequest userLoginRequest) {
// 模拟数据库查询
UserModel userModel = UserModel.builder().id("001").name("老板").build();
log.info("用户校验通过:{}", userLoginRequest);
return userModel;
}
/**
* 钩子方法
*
* @return
*/
protected boolean needFillSpecific() {
return false;
}
/**
* 填写具体用户信息, 如果需要填充, 执行子类中的重写的方法
*
* @param userModel
* @return
*/
protected void fillSpecific(UserModel userModel) {
}
/**
* 组装token
*
* @param userModel
*/
private void createToken(UserModel userModel) {
// 组装token
}
}
3.2.2 各个子类的方法实
boss 用户需要填充权限信息, 所以需要重写模板类中的方法
/**
* @author canxiusi.yan
* @description BossLoginService
* @date 2022/2/21 18:39
*/
@Service
public class BossLoginTemplate extends UserLoginTemplate {
@Override
protected boolean needFillSpecific() {
// 老板登录需要覆盖登钩子方法
return true;
}
@Override
protected void fillSpecific(UserModel userModel) {
// 单独填充一些独有信息
userModel.setPermission("老板填充信息");
}
}
顾客用户不需要填充信息, 所以不用重写模板类中的方法
/**
* @author canxiusi.yan
* @description StroeLoginTemplate
* @date 2022/2/22 11:00
*/
@Service
public class StoreLoginTemplate extends UserLoginTemplate {
}
钩子方法的用处很巧妙, 我们也可以有 "默认不做事情的方法", 把它称为钩子方法, 子类可以视情况决定要不要覆盖此方法, 比如在本例中, 老板登录需要填充更具体的登录人信息, 可以覆盖方法并返回 true , 而对于一般用户登录, 则不用覆盖此方法, 书中把这个骚操作称为挂钩, 子类有能力对业务逻辑的不同点进行, 并决定要不要进行挂钩
3.3 总结
模板方法模式定义了一组其子类共有的方法, 当我们的业务中, 有大量公用步骤的时候, 可以考虑使用模板方法模式对代码进行复用