前言
什么是策略模式？
策略模式（Strategy Pattern）是一种面向对象设计模式，它定义了算法族（一组相似的算法），并且将每个算法都封装起来，使得它们可以互相替换。策略模式让算法的变化独立于使用算法的客户端。
在策略模式中，定义一个抽象的策略接口或者抽象类来封装不同的具体算法实现，并由客户端根据需要动态选择使用哪种算法。这种方式支持应用程序灵活地更换算法和扩展算法，而无需修改已有代码。此外，策略模式可以减少大量的 if-else 语句，提高代码的可读性和可维护性。
策略模式通常包含三个角色：
环境(Context)角色：通过一个持有某个策略实例的变量来调用具体的策略算法。
抽象策略(Strategy)角色：定义了一个公共的接口或抽象类，规定了所有具体策略角色必须实现的方法。
具体策略(Concrete Strategy)角色：实现了抽象策略接口或抽象类中定义的方法，提供具体的处理逻辑。每个具体策略角色都代表一个算法的具体实现。
在使用策略模式时，首先定义一个抽象的策略接口或抽象类，然后定义具体的策略实现类，最后将策略实现类注入到需要使用的类中。这样可以让客户端通过改变具体的策略实现类，来灵活地选择不同的算法，从而实现目标。
一、开始学习
本次案例，通过支付的例子来完成一个案例。
1、新建项目，结构如下
2、添加 spring 依赖
<!-- spring 的核心依赖 -->
<dependencies>
<!-- https://mvnrepository.com/artifact/org.springframework/spring-context -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.3.23</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.4.5</version>
</dependency>
</dependencies>3、在 service 包下新建一个 Payment 接口，在 impl 包下新建 AliPayment、WeChartPayment实现类
Payment 接口
/**
* @Date 2023-10-07
* @Author qiu
* 支付接口，对应有不同的实现
*/
public interface Payment {
/**
* 支付方法
* @param money
*/
void pay(BigDecimal money);
}
Alipayment 实现类
/**
* @Date 2023-10-07
* @Author qiu
* 支付宝支付
*/
@Service
@Slf4j
public class AliPayment implements Payment {
@Override
public void pay(BigDecimal money) {
log.info("使用支付宝支付金额： " + money.doubleValue());
}
}
WeChartPayment 实现类
/**
* @Date 2023-10-07
* @Author qiu
* 微信支付
*/
@Slf4j
@Service
public class WeChartPayment implements Payment {
@Override
public void pay(BigDecimal money) {
log.info("使用微信支付金额：" + money.doubleValue());
}
}看下图分析：
在策略模式中，定义一个抽象的策略接口或者抽象类来封装不同的具体算法实现，并由客户端根据需要动态选择使用哪种算法。
现在大家可以理解这句话的意思了吧，我把支付的方法抽象出来，定义一个接口，但是具体的实现交给了实现它的实现类去完成，每一种实现都是独立的，如果现在需要新增一个支付方式该怎么办呢？很简单，只需要再新增一个实现类去继承 Payment 支付接口即可，具体的实现也是这个实现类去完成，把每个不同类型的支付方式都分别交给独立的实现类去完成，交给用户去选择。这样写代码也更加方便维护，使用微信支付出现问题时我们只需要去修改 WeChartPayment 实现类的代码，不需要改动其他的实现类的代码，而且修改 WeChartPayment 的代码也不会影响到其他实现类的正常运行，这就是策略模式。
4、如何使用 spring 注入所有的实现类呢？
1）新增一个 PaymentContext 类
@Service
/**
* 利用 Lombok 生成一个带参数的构造方法
* 这样即可以通过构造方法直接注入
*/
@RequiredArgsConstructor
public class PaymentContext {
/**
* 构造方法注入
* 注入一个 map 集合，spring 会将 Payment 接口的所有实现类
* 一并保存到 map 中
* key(bean 的 id) 为支付类型， value 是具体的支付策略实现
*/
private final Map<String, Payment> paymentMap;
/**
* 根据支付类型选择具体的策略来完成支付
* @param paymentType 支付类型
* @param money 支付金额
*/
public void pay(String paymentType, BigDecimal money){
Payment payment = paymentMap.get(paymentType);
payment.pay(money);
}
}
这是一个策略上下文类
PaymentContext，它使用了构造方法注入来获取支付策略的集合。注解
@Service表明该类是一个服务类，用于处理业务逻辑。注解
@RequiredArgsConstructor是 Lombok 提供的注解，它会生成一个带有final字段的构造函数。在这个类中，通过构造方法注入了一个Map<String, Payment>类型的成员变量paymentMap。Spring 会将所有实现了Payment接口的 bean 注册到这个paymentMap中，key 为 bean 的 id，value 为相应的具体支付策略实现。在
pay方法中，通过传入的paymentType参数从paymentMap中获取对应的具体支付策略，并调用其pay方法来完成支付操作。通过这种方式，可以在策略上下文中动态选择具体的支付策略进行支付。通过构造方法注入支付策略的集合，可以方便地扩展和管理不同支付类型的策略。
2）在 controller 包下新增一个 PaymentContorller 类
@Controller
@RequiredArgsConstructor
public class PaymentController {
/**
* 注入策略上下文
*/
private final PaymentContext context;
public void pay(String type, BigDecimal money) {
context.pay(type, money);
}
}
这是一个支付控制器类
PaymentController，它使用了策略模式来处理不同类型的支付。注解
@Controller表明该类是一个控制器，用于接收和处理请求。注解
@RequiredArgsConstructor是 Lombok 提供的注解，它会生成一个包含所有final和@NonNull注解的字段的构造函数。控制器类中声明了一个名为
context的PaymentContext类型的成员变量，用于存储策略上下文对象。在
pay方法中，根据传入的type和money参数，调用context的pay方法来执行具体的支付逻辑。这里的pay方法是策略上下文对象中定义的方法，用于根据支付类型调用相应的具体支付策略。通过这种方式，可以将不同类型的支付逻辑封装到不同的具体支付策略中，并通过策略上下文来选择并执行相应的支付策略。这样可以实现支付方式的灵活切换和扩展。
5、在 resources 下新建一个 spring 的 xml 文件 beans.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd">
<!-- 启用包扫描 -->
<context:component-scan base-package="edu.nf.ch09"/>
</beans>6、测试
public class Main {
public static void main(String[] args) {
ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml");
PaymentContext bean = context.getBean(PaymentContext.class);
bean.pay("weChartPayment", new BigDecimal("100"));
}
}运行结果
这是一个启动类
Main，它通过 Spring 容器来获取支付上下文对象，并调用其pay方法进行支付操作。在
main方法中，利用ClassPathXmlApplicationContext类加载 classpath 下的beans.xml文件，从而创建一个 Spring 容器。使用容器的
getBean方法获取 id 为paymentContext的 bean 对象，即上下文对象PaymentContext。最后，通过调用上下文对象的
pay方法来完成支付操作。这里传入的第一个参数是支付类型，在beans.xml中扫描的 bean id 即为对应的支付类型；第二个参数为支付金额。在运行动图中可以看到，我们需要使用哪种支付方式就把它的 bean id写进去即可。
通过 Spring 容器的支持，我们可以方便地管理和维护各个支付类型的具体支付策略，同时也能够方便地进行扩展和配置。
二、使用策略模式注入所有实现类的好处
使用策略模式注入所有实现类的好处主要有以下几个方面：
解耦性：通过策略模式，将具体的实现类与调用它们的类解耦。调用方只需要依赖于抽象的策略接口或基类，而不需要关心具体的实现类。这样可以降低类之间的耦合度，并且使得系统更加灵活和可维护。
可扩展性：当新增一种支付类型时，只需实现相应的支付策略，并注册到容器中即可，无需修改调用方的代码。通过容器自动注入所有实现类，实现类的新增和移除变得方便快捷，可以根据业务需求随时扩展支付策略。
可配置性：通过注入所有实现类，可以将不同的实现类配置到容器的配置文件中，而不需要修改源代码。这样在不同的环境中，可以通过简单的配置文件修改支付策略的选择，而无需重新编译和部署代码。
单一职责原则：通过策略模式，每个具体的支付策略类只需要关注自身特定的支付逻辑，符合单一职责原则。这样可以提高代码的可读性、可维护性和可测试性。
总之，使用策略模式注入所有实现类具有解耦性、可扩展性、可配置性和单一职责原则等优点，使得系统更加灵活、可维护和可测试。
三、gitee 案例
案例完整地址：https://gitee.com/qiu-feng1/spring-framework.git
