前言
在业务开发中,我们最经常使用到的判断就是if…else,只要涉及到多种策略的实现方式,我们脑海中就会使用这个判断。有时候产品需求的不明确,一个版本迭代来一种判断,随着时间的推移,这个实现方法就会变得又长又臭,那有什么办法可以来觉得呢,通过学习策略模式,他能够很好的帮我们解决这个问题。
纲要
在学习之前,有一句话我觉得比设计模式更重要。
设计原则和思想比设计模式更加普适和重要
什么是策略模式?
简单的来说,就是定义一系列算法,封装每个算法,并使它们可以互换。
策略让算法独立于使用它的客户端而变化。
1. 三个关键角色
三个关键角色
2. 目的
实现不同的策略,将策略分离
3. 为什么要使用策略模式
主要有三个原因
为什么使用策略模式?
优缺点
优缺点
场景分析
通过第一部分,我们对策略模式有了一个大概的认识,那他主要针对于什么场景呢
- 需要动态切换不同算法
- 多重的条件选择业务场景
- 客户端只关心调用,不关心算法细节
- 分离策略
源码案例
源码案例
我们可以通过优秀的代码中学习策略模式的实现
SimpleInstantiationStrategy中分析出它的关键角色
可以从命名中看出,SimpleInstantiationStrategy是其中的某一个策略,我们在写策略模式的时候最好也以Strategy为结尾,表名这就是个策略。
1.抽象策略类
1 | less复制代码public interface InstantiationStrategy { |
2.具体策略类
1 | less复制代码public class SimpleInstantiationStrategy implements InstantiationStrategy { |
3.上下文信息类
这里没有找到上下文信息类,我们可以理解为上下文就是来存取策略的一个地方。在这里可以与工厂模式有一个很好的结合,在实践demo中给大家展示。
实践
与工厂模式结合:
上下文信息类:
1 | typescript复制代码@Component |
抽象策略(Strategy)角色:
1 | csharp复制代码public interface RuleStrategy<T extends RulesProcessorBO> { |
环境角色(组件,直接调用工厂):
1 | typescript复制代码@Component |
具体策略(ConcreteStrategy)角色:
1 | less复制代码@Component |
这就是一个策略模式的实现,可以看出代码量一下就上去了,如果在规则简单而且情况少的情况下,我们可能就不需要再去使用策略模式,因为它不够直观。
本文转载自: 掘金