《Head First 设计模式》学习笔记---模板方法模式实现代码复用

一. 使用场景

        业务开发中经常会遇到这种问题, 清楚该业务需求所需的关键步骤, 并且知道其执行顺序, 但是未知其具体的实现细节, 或者说实现细节需要特定的条件才能执行

        比如, 去银行办理业务一般要经过以下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 总结

        模板方法模式定义了一组其子类共有的方法, 当我们的业务中, 有大量公用步骤的时候, 可以考虑使用模板方法模式对代码进行复用