什么是「模板模式」？
抽象类里定义好算法的执行步骤和具体算法，以及可能发生变化的算法定义为抽象方法。不同的子类继承该抽象类，并实现父类的抽象方法。
模板模式的优势：
- 不变的算法被继承复用：不变的部分高度封装、复用。
- 变化的算法子类继承并具体实现：变化的部分子类只需要具体实现抽象的部分即可，方便扩展，且可无限扩展。
什么真实业务场景可以用「模板模式」？
满足如下要求的所有场景：
算法执行的步骤是稳定不变的，但是具体的某些算法可能存在变化的场景。
怎么理解，举个例子：比如说你煮个面，必然需要先烧水，水烧开之后再放面进去，以上的流程我们称之为煮面过程。可知：这个煮面过程的步骤是稳定不变的，但是在不同的环境烧水的方式可能不尽相同，也许有的人用天然气烧水、有的人用电磁炉烧水、有的人用柴火烧水，等等。我们可以得到以下结论：
- 煮面过程的步骤是稳定不变的
- 煮面过程的烧水方式是可变的
我们有哪些真实业务场景可以用「模板模式」呢？
比如抽奖系统的抽奖接口，为什么：
- 抽奖的步骤是稳定不变的 -> 不变的算法执行步骤
- 不同抽奖类型活动在某些逻辑处理方式可能不同 -> 变的某些算法
怎么用「模板模式」？
关于怎么用，完全可以生搬硬套我总结的使用设计模式的四个步骤：
- 业务梳理
- 业务流程图
- 代码建模
- 代码 demo
业务梳理
各种抽奖场景（红包雨、糖果雨、打地鼠、大转盘（九宫格）、考眼力、答题闯关、游戏闯关、支付刮刮乐、积分刮刮乐等等），按照真实业务需求梳理了以下抽奖业务抽奖接口的大致文本流程。
结论：
- 主逻辑是稳定不变的
- 其他参数校验和获取 node 奖品信息的算法是可变的
业务流程图
代码建模
通过上面的分析我们可以得到：
一个抽象类
- 具体共有方法Run，里面定义了算法的执行步骤
- 具体私有方法，不会发生变化的具体方法
- 抽象方法，会发生变化的方法
子类一（按时间抽奖类型）
- 继承抽象类父类
- 实现抽象方法
子类二（按抽奖次数抽奖类型）
- 继承抽象类父类
- 实现抽象方法
子类三（按数额范围区间抽奖）
- 继承抽象类父类
- 实现抽象方法
若有收获，就点个赞吧
0 人点赞
