仅需两步即可完成:
1. 打开 12306 项目 开源仓库主页,右上角点个 Star
2. 点击下方【同意授权检测】按钮,同意获取 API 权限进行检测
本章节文档,将在 Star 12306 仓库后正常开放展示
策略模式在 GoF 的《设计模式》一书中,是这样定义的:
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
策略设计模式(Strategy Pattern)是一种面向对象设计模式,它定义了一系列算法,并将每个算法封装起来,使它们可以相互替换。这种模式使得算法可以独立于使用它们的客户端而变化。
策略设计模式包含三个主要的角色:
在策略设计模式中,环境持有一个策略对象,并通过调用策略的算法来完成具体的任务。策略对象可以根据需要进行替换,从而实现不同的算法实现,并且可以在运行时动态地更改策略对象。
看到上面的介绍可能不太明白策略模式具体为何物,这里会从最基本的代码说起,一步一步彻底掌握此模式。
下述代码可能大家都能联想出对应的业务,根据对应的优惠类型,对价格作出相应的优惠。
这段代码是能够满足项目中业务需求的,而且很多已上线生产环境的代码也有这类代码。但是,这一段代码存在存在两个弊端:
如何运用策略模式优化上述代码,使程序设计看着简约、可扩展等特性。
将上述代码块改造为策略设计模式,大致需要三个步骤。
目前把抽象策略接口、具体的策略实现类以及策略工厂都已经创建了,现在可以看一下客户端需要如何调用,又是如何对客户端屏蔽具体实现细节的。
根据代码块图片得知,具体策略类是从策略工厂中获取,确实是取消了 if-else 设计,在工厂中使用 Map 存储策略实现。获取到策略类后执行具体的优惠策略方法就可以获取优惠后的金额。
通过分析大家得知,目前这种设计确实将应用代码的复杂性降低了。如果新增一个优惠策略,只需要新增一个策略算法实现类即可。但是,添加一个策略算法实现,意味着需要改动策略工厂中的代码,还是不符合开闭原则。
如何完整实现符合开闭原则的策略模式,需要借助 Spring 的帮助,详细案例请继续往下看。
最近项目中设计的一个功能用到了策略模式,分为两类角色,笔者负责定义抽象策略接口以及策略工厂,不同的策略算法需要各个业务方去实现,可以联想到上文中的优惠券功能。因为是 Spring 项目,所以都是按照 Spring 的方式进行处理。
可以看到,比对上面的示例代码,有两处明显的变化:
小贴士:为了阅读方便,mark() 返回直接使用字符串替代,读者朋友在返回标示时最好使用枚举定义。
接下来继续查看抽象策略工厂如何改造,才能满足开闭原则。
通过 InitializingBean 接口实现中调用 IOC 容器查找对应策略实现,随后将策略实现 mark() 方法返回值作为 key, 策略实现本身作为 value 添加到 Map 容器中等待客户端的调用。
这里使用的 SpringBoot 测试类,注入策略工厂 Bean,通过策略工厂选择出具体的策略算法类,继而通过算法获取到优惠后的价格。
总结下本小节,我们通过和 Spring 结合的方式,通过策略设计模式对文初的代码块进行了两块优化:应对代码的复杂性,让其满足开闭原则。
更具体一些呢就是 通过抽象策略算法类减少代码的复杂性,继而通过 Spring 的一些特性同时满足了开闭原则,现在来了新需求只要添加新的策略类即可,健壮易扩展。
策略设计模式的优点包括:
需要注意的是,在使用策略设计模式时需要注意以下几点:
自己用肯定觉得不够,必要时候还得看看设计开源框架源码的大佬们如何在代码中运用策略模式的。
在马哥了解中,JDK、Spring、SpringMvc、Mybatis、Dubbo 等等都运用了策略设计模式,这里就以 Mybatis 举例说明。
Mybatis 中 Executor 代表执行器,负责增删改查的具体操作。其中用到了两种设计模式,模版方法以及策略模式。
上述代码块发生在 Configuration 类中创建执行器 Executor,通过 executorType 判断创建不同的策略算法。
上述代码块并没有彻底消除 if-else,因为 Mybatis 中执行器策略基本是固定的,也就是说它只会有这些 if-else 判断,基本不会新增或修改。如果非要消除 if-else,可以这么搞,这里写一下伪代码。
这种方式叫做 "查表法",通过策略工厂实现消除 if-else 分支。最后,Mybatis 太过详细的设计这里不再赘述,有兴趣的小伙伴可以去把源码下载啃一啃。
到了这里可能有读者看出了问题,策略模式就算消除了 if-else 但是如果添加新的策略类,不还是会违反开闭原则么?
没错,因为 Mybatis 本身没有引入 Spring 依赖,所以没有办法借助 IOC 容器实现开闭原则。Spring 是一种开闭原则解决方式,那还有没有别的解决方式?
解决方式有很多,开闭原则核心就是 对原有代码修改关闭,对新增代码开放。可以通过扫描指定包下的自定义注解亦或者通过 instanceof 判断是否继承自某接口都可以。
可能细心的小伙伴会发现一个问题,当业务使用越来越多的情况下,重复定义 DiscountStrategy
以及 DiscountStrategyFactory
会增加系统冗余代码量。
可以考虑将这两个基础类抽象出来,作为基础组件库中的通用组件,供所有系统下的业务使用,从而避免代码冗余。
定义抽象策略处理接口,添加有返回值和无返回值接口。
package org.opengoofy.congomall.springboot.starter.designpattern.strategy;
/**
* 策略执行抽象
*/
public interface AbstractExecuteStrategy<REQUEST, RESPONSE> {
/**
* 执行策略标识
*/
String mark();
/**
* 执行策略
*
* @param requestParam 执行策略入参
*/
default void execute(REQUEST requestParam) {
}
/**
* 执行策略,带返回值
*
* @param requestParam 执行策略入参
* @return 执行策略后返回值
*/
default RESPONSE executeResp(REQUEST requestParam) {
return null;
}
}
添加策略选择器,通过订阅 Spring 初始化事件执行扫描所有策略模式接口执行器,并根据 mark 方法定义标识添加到 abstractExecuteStrategyMap
容器中。
客户端在实际业务中使用 AbstractStrategyChoose#choose
即可完成策略模式实现。
package org.opengoofy.congomall.springboot.starter.designpattern.strategy;
import org.opengoofy.congomall.springboot.starter.base.ApplicationContextHolder;
import org.opengoofy.congomall.springboot.starter.base.init.ApplicationInitializingEvent;
import org.opengoofy.congomall.springboot.starter.convention.exception.ServiceException;
import org.springframework.context.ApplicationListener;
import java.util.HashMap;
import java.util.Map;
import java.util.Optional;
/**
* 策略选择器
*/
public class AbstractStrategyChoose implements ApplicationListener<ApplicationInitializingEvent> {
/**
* 执行策略集合
*/
private final Map<String, AbstractExecuteStrategy> abstractExecuteStrategyMap = new HashMap<>();
/**
* 根据 mark 查询具体策略
*
* @param mark 策略标识
* @return 实际执行策略
*/
public AbstractExecuteStrategy choose(String mark) {
return Optional.ofNullable(abstractExecuteStrategyMap.get(mark)).orElseThrow(() -> new ServiceException(String.format("[%s] 策略未定义", mark)));
}
/**
* 根据 mark 查询具体策略并执行
*
* @param mark 策略标识
* @param requestParam 执行策略入参
* @param <REQUEST> 执行策略入参范型
*/
public <REQUEST> void chooseAndExecute(String mark, REQUEST requestParam) {
AbstractExecuteStrategy executeStrategy = choose(mark);
executeStrategy.execute(requestParam);
}
/**
* 根据 mark 查询具体策略并执行,带返回结果
*
* @param mark 策略标识
* @param requestParam 执行策略入参
* @param <REQUEST> 执行策略入参范型
* @param <RESPONSE> 执行策略出参范型
* @return
*/
public <REQUEST, RESPONSE> RESPONSE chooseAndExecuteResp(String mark, REQUEST requestParam) {
AbstractExecuteStrategy executeStrategy = choose(mark);
return (RESPONSE) executeStrategy.executeResp(requestParam);
}
@Override
public void onApplicationEvent(ApplicationInitializingEvent event) {
Map<String, AbstractExecuteStrategy> actual = ApplicationContextHolder.getBeansOfType(AbstractExecuteStrategy.class);
actual.forEach((beanName, bean) -> {
AbstractExecuteStrategy beanExist = abstractExecuteStrategyMap.get(bean.mark());
if (beanExist != null) {
throw new ServiceException(String.format("[%s] Duplicate execution policy", bean.mark()));
}
abstractExecuteStrategyMap.put(bean.mark(), bean);
});
}
}
这两个实现已经被放置在基础组件库中,如果业务需要使用策略模式,则无需重新定义。
总的来说,策略模式是一种非常有用的设计模式,它可以帮助我们在运行时动态地选择不同的算法实现,从而提高代码的灵活性、可维护性和可扩展性。
通过将算法实现封装在不同的策略类中,并定义一个策略接口来描述算法,策略模式使得客户端可以独立于算法实现进行编程,同时也可以方便地更换算法实现或者添加新的算法实现。
策略模式的优点包括提高代码的灵活性、可维护性、可扩展性和复用性,同时也可以避免使用大量的条件语句和提高代码的可读性。
需要注意的是,在使用策略模式时需要遵循一些设计原则,例如开闭原则、单一职责原则和依赖倒置原则等,以确保代码的高内聚性和低耦合度。
此外,策略模式适用于需要在运行时动态选择不同算法实现的场景,如果算法实现不需要动态切换或者算法实现较为简单,策略模式可能会显得过于复杂。
因此,在使用策略模式时需要根据具体的需求和场景进行判断和选择。
🚀 系统提示:访问文档失败 🚀
原因:开源不易,文档仅对已 Star 12306 项目的用户开放。
操作步骤:点击下方「Gitee 项目」和「GitHub 项目」按钮 Star 项目即可。 12306 所有端的代码都会完全开源,为了更好地完善这个框架,希望大家多多支持。