策略模式精讲+实战

2026/7/3 15:03:51

策略模式（Strategy Pattern）精讲 —— 结合 Spring 实战

1. 官方标准定义（GoF 原话）

定义一组算法，将每个算法都封装起来，并且使它们之间可以互相替换。该模式让算法的变化独立于使用算法的客户端（调用方）。核心原则：针对接口编程，而不是针对实现编程。策略模式（Strategy Pattern）是 GoF 23 种设计模式中的行为型模式。

2. 一句话"人话"解读

它是一个策略路由器。你只需要告诉上下文（Context）你想要什么"策略标识"（比如"ALIPAY"），它就会自动把对应的"技能/算法"（比如支付宝支付逻辑）拿出来执行，而调用方完全不用关心底层是怎么if-else判断类型的。

3. 模式的核心三要素（结构定义）

为满足上面的定义，模式必须包含以下 3 个角色：

角色	职责	对应代码
抽象策略（Strategy）	定义一个公共接口，所有算法都遵循这个"合同"	`PaymentStrategy`接口
具体策略（ConcreteStrategy）	实现接口的具体类，封装了具体的业务算法	`AlipayStrategy`、`WechatStrategy`
上下文（Context）	持有策略引用，负责根据条件路由到具体策略	`PaymentContext`

设计原则

封装变化：找出应用中可能需要变化的部分，把它们独立出来
面向接口编程：策略的具体实现依赖接口，而不是依赖实现类
组合优于继承：Context 通过组合持有一个 Strategy 引用，而不是继承具体策略

4. 为什么这个定义很重要？（结合 Spring 场景）

"互相替换"：因为 Spring 把策略类注入了Map<String, Strategy>，只要type匹配，随时可以替换某个策略的实现类，调用方完全无感知。新增策略时，客户端代码完全不用改，完美符合"开闭原则"。
"变化独立于客户端"：客户端（Controller）只需要传"WECHAT"，不需要知道微信支付类是否被 AOP 代理了。无论注入的是原始类还是代理类，代码都能正常运行——这就是接口编程的威力。

5. 代码实战（解决支付场景）

假设有一个支付系统，支持支付宝、微信等多种渠道。我们将使用 Spring 的依赖注入特性来优雅实现。

5.1 原始反面案例（使用`instanceof`）

// ❌ 反面教材：每当新增支付方式，都要修改此处代码，违反开闭原则 public String pay(Object channel) { if (channel instanceof Alipay) { // 支付宝逻辑 } else if (channel instanceof WechatPay) { // 微信逻辑 } throw new UnsupportedOperationException(); }

5.2 重构为策略模式（优雅实现）

第一步：定义策略接口

public interface PaymentStrategy { // 策略标识（用于前端传参，替代 instanceof 判断） String getType(); // 执行支付 void pay(Double amount); }

第二步：实现具体策略（交给 Spring 管理）

@Component public class AlipayStrategy implements PaymentStrategy { @Override public String getType() { return "ALIPAY"; } @Override public void pay(Double amount) { System.out.println("使用支付宝支付：" + amount); // 此处调用支付宝 SDK... } } @Component public class WechatStrategy implements PaymentStrategy { @Override public String getType() { return "WECHAT"; } @Override public void pay(Double amount) { System.out.println("使用微信支付：" + amount); // 此处调用微信 SDK... } }

第三步：创建策略上下文（核心工厂）

利用 Spring 的构造函数注入，将所有的策略List自动转换为Map<String, Strategy>。此时已彻底消灭instanceof。

@Component public class PaymentContext { private final Map<String, PaymentStrategy> strategyMap; @Autowired public PaymentContext(List<PaymentStrategy> strategies) { // 将 List 转为 Map，Key 为策略自定义的类型标识 this.strategyMap = strategies.stream() .collect(Collectors.toMap(PaymentStrategy::getType, Function.identity())); } // 对外统一调用接口 public void executePay(String type, Double amount) { PaymentStrategy strategy = strategyMap.get(type); if (strategy == null) { throw new IllegalArgumentException("不支持的支付方式: " + type); } strategy.pay(amount); } }

第四步：Controller 层调用

@RestController @RequestMapping("/api/pay") public class PayController { @Autowired private PaymentContext paymentContext; @PostMapping public String pay(@RequestParam String type, @RequestParam Double amount) { // 前端传入 "ALIPAY" 或 "WECHAT"，无需任何类型判断 paymentContext.executePay(type, amount); return "支付成功"; } }

6. 策略模式 vs`instanceof`的优势

对比维度	`if-else`+`instanceof`	策略模式（Map 路由）
开闭原则	违反（新增渠道需修改原有类）	符合（新增渠道只需新建类加`@Component`）
代码可读性	随着分支增多，逻辑臃肿难维护	路由清晰，业务逻辑内聚在各自类中
测试难度	需要 mock 大量无关分支	可单独测试每个策略类
运行时性能	链式判断，O(N) 复杂度	Map 哈希查找，O(1) 复杂度

7. 联动避坑（Spring 代理问题）

如果具体策略类（如AlipayStrategy）本身被@Transactional或@Cacheable注解，Spring 会为其生成代理对象。此时直接通过new创建实例会失去代理能力，必须通过 Spring 容器获取策略实例。这正是策略上下文（Context）通过依赖注入管理策略实例的重要原因。