本篇为设计模式第四篇,前三篇戳下方链接阅读:
什么是模板模式
模板模式(Template Pattern) 又叫模板方法模式,其定义了操作的流程,并将流程中的某些步骤延迟到子类中进行实现,使得子类在不改变操作流程的前提下,即可重新定义该操作的某些特定步骤。例如做菜,操作流程一般为 “准备菜”->“放油”->“炒菜”->“调味”->“装盘”,但可能对于不同的菜要放不同类型的油,不同的菜调味方式也可能不一样。
何时使用模板模式
当一个操作的流程较为复杂,可分为多个步骤,且对于不同的操作实现类,流程步骤相同,只有部分特定步骤才需要自定义,此时可以考虑使用模板模式。如果一个操作不复杂(即只有一个步骤),或者不存在相同的流程,那么应该使用策略模式。从这也可看出模板模式和策略模式的区别:策略模式关注的是多种策略(广度),而模板模式只关注同种策略(相同流程),但是具备多个步骤,且特定步骤可自定义(深度)。
愉快地使用模板模式
背景
我们平台的动态表单在配置表单项的过程中,每新增一个表单项,都要根据表单项的组件类型(例如 单行文本框、下拉选择框)和当前输入的各种配置来转换好对应的 Schema 并保存在 DB 中。一开始,转换的代码逻辑大概是这样的:
1 | ini复制代码public class FormItemConverter { |
很明显,这份代码违反了 开闭原则(对扩展开放,对修改关闭):如果此时需要添加一种新的表单项(包含特殊的组件属性),那么不可避免的要修改 convert 方法来进行新表单项的特殊处理。观察上面的代码,将配置转变为表单项 这个操作,满足以下流程:
- 创建表单项,并设置通用的表单项属性,然后再对不同表单项的特殊属性进行处理
- 创建组件属性,处理通用的组件属性,然后再对不同组件的特殊属性进行处理
- 创建约束规则,处理通用的约束规则,然后再对不同表单项的特性约束规则进行处理
这不正是符合模板模式的使用场景(操作流程固定,特殊步骤可自定义处理)吗?基于上面这个场景,下面我就分享一下我目前基于 Spring 实现模板模式的 “最佳套路”(如果你有更好的套路,欢迎赐教和讨论哦)~
方案
定义出模板
即首先定义出表单项转换的操作流程,即如下的 convert 方法(使用 final 修饰,确保子类不可修改操作流程):
1 | scss复制代码public abstract class FormItemConverter { |
模板的实现
针对不同的表单项,对特殊步骤进行自定义处理:
1 | scala复制代码/** * 下拉选择框的转换器 */@Componentpublic class DropdownSelectConverter extends FormItemConverter { |
制作简单工厂
1 | typescript复制代码@Componentpublic class FormItemConverterFactory { |
投入使用
1 | java复制代码@Componentpublic class FormItemManagerImpl implements FormItemManager { |
Factory 只负责获取 Converter,每个 Converter 只负责对应表单项的转换功能,Manager 只负责逻辑编排,从而达到功能上的 “低耦合高内聚”。
设想一次扩展
此时要加入一种新的表单项 —— 数字选择器(NUMBER_PICKER),它有着特殊的约束条件:最小值和最大值,输入到 FormItemConfig 时分别为 minNumer 和 maxNumber。
1 | scala复制代码@Componentpublic class NumberPickerConverter extends FormItemConverter { |
此时,我们只需要添加对应的枚举和实现对应的 FormItemConverter,并不需要修改任何逻辑代码,因为 Spring 启动时会自动帮我们处理好 NUMBER_PICKER 和 NumberPickerConverter 的关联关系 —— 完美符合 “开闭原则”。
本文转载自: 掘金