作者|周密(之叶)
策略模式(Strategy Pattern)定义了一组策略,分别在不同类中封装起来,每种策略都可以根据当前场景相互替换,从而使策略的变化可以独立于操作者。比如我们要去某个地方,会根据距离的不同(或者是根据手头经济状况)来选择不同的出行方式(共享单车、坐公交、滴滴打车等等),这些出行方式即不同的策略。
何时使用策略模式
阿里开发规约-编程规约-控制语句-第六条 :超过 3 层的 if-else 的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现。相信大家都见过这种代码:
1 | arduino复制代码if (conditionA) { |
这种代码虽然写起来简单,但是很明显违反了面向对象的 2 个基本原则:
- 单一职责原则(一个类应该只有一个发生变化的原因):因为之后修改任何一个逻辑,当前类都会被修改
- 开闭原则(对扩展开放,对修改关闭):如果此时需要添加(删除)某个逻辑,那么不可避免的要修改原来的代码
因为违反了以上两个原则,尤其是当 if-else 块中的代码量比较大时,后续代码的扩展和维护就会逐渐变得非常困难且容易出错,使用卫语句也同样避免不了以上两个问题。因此根据我的经验,得出一个我个人认为比较好的实践:
- if-else 不超过 2 层,块中代码 1~5 行,直接写到块中,否则封装为方法
- if-else 超过 2 层,但块中的代码不超过 3 行,尽量使用卫语句
- if-else 超过 2 层,且块中代码超过 3 行,尽量使用策略模式
愉快地使用策略模式
在 Spring 中,实现策略模式的方法多种多样,下面我分享一下我目前实现策略模式的 “最佳套路”(如果你有更好的套路,欢迎赐教,一起讨论哦)。
需求背景
我们平台的动态表单,之前专门用于模型输入的提交。现在业务方希望对表单能力进行开放,除了可用于模型提交,还可以用于业务方指定功能的提交(方式设计为绑定一个 HSF 泛化服务,HSF 即淘系内部的 RPC 框架)。加上我们在配置表单时的 “预览模式” 下的提交,那么表单目前便有以下三种提交类型:
- 预览表单时的提交
- 模型输入时的提交
- 绑定 HSF 时的提交
现在,有请我的 “最佳套路” 上场。
第一步,定义策略接口
首先定义策略的接口,包括两个方法:
1、获取策略类型的方法
2、处理策略逻辑的方法
1 | csharp复制代码/** |
1 | less复制代码/** |
其中,FormSubmitHandler 的 getSubmitType 方法用来获取表单的提交类型(即策略类型),用于根据客户端传递的参数直接获取到对应的策略实现;客户端传递的相关参数都被封装为 FormSubmitRequest,传递给 handleSubmit 进行处理。
第二步,相关策略实现
预览表单时的提交
1 | typescript复制代码@Component |
模型输入时的提交
1 | kotlin复制代码@Component |
HSF 模式的提交
1 | typescript复制代码@Component |
第三步,建立策略的简单工厂
1 | typescript复制代码@Component |
我们让 FormSubmitHandlerFactory 实现 InitializingBean 接口,在 afterPropertiesSet 方法中,基于 Spring 容器将所有 FormSubmitHandler 自动注册到 FORM_SUBMIT_HANDLER_MAP,从而 Spring 容器启动完成后, getHandler 方法可以直接通过 submitType 来获取对应的表单提交处理器。
第四步,使用 & 测试
在表单服务中,我们通过 FormSubmitHandlerFactory 来获取对应的表单提交处理器,从而处理不同类型的提交:
1 | typescript复制代码@Service |
Factory 只负责获取 Handler,Handler 只负责处理具体的提交,Service 只负责逻辑编排,从而达到功能上的 “低耦合高内聚”。
写一个简单的 Controller:
1 | less复制代码@RestController |
最后来个简单的测试:
我感觉到了,这就是非常流畅的感觉~
设想一次扩展
如果我们需要加入一个新的策略,比如绑定 FaaS 函数的提交,我们只需要添加一个新的策略实现即可:
1 | typescript复制代码@Component |
此时不需要修改任何代码,因为 Spring 容器重启时会自动将 FormFaasSubmitHandler 注册到 FormSubmitHandlerFactory 中 —— 面向 Spring 编程,太香惹~
本文转载自: 掘金