📝 Java 设计模式之——策略模式（Strategy Pattern）实战笔记

有时候，写代码最怕的不是 bug，而是看着自己写的几百行 if-else，突然陷入人生怀疑…

---

1. 为什么会想到策略模式？

Java 项目写久了，肯定会遇到这种场景：

• 系统有一大堆类似的功能实现，但差别在一些细节上
• 功能会不断新增（比如老板今天说要加微信支付，明天又来一个银联支付）
• 你一开始写得很爽，后来 if-else 越写越多，代码一摸就是一长串条件判断
• 改一个地方，全局都要回归测试，生怕改挂了

这种情况… 说人话就是：变化和不变化的东西全揉在一锅粥里了。
想优雅一点？这就是策略模式该出场的时机。

---

2. 策略模式是啥？

官方说法：定义一组算法，将它们封装起来，使它们可以互相替换，且不影响使用算法的用户。

说人话：
就是把一堆“做事的方式”（策略）都单独封装成类，什么时候用哪个策略，你在运行时自己选就行。
这样：

• 你不用到处加 if-else 分支
• 策略可以随意扩展、不影响原来的业务逻辑
• 想切换就换，零侵入

---

3. 简单 UML 示意

不用背，理解就好👇

Context(环境) —— 持有一个策略接口（可替换）
Strategy(策略接口) —— 定义要做的事情
ConcreteStrategyA/B/... —— 实际做事的人（多种方式）

---

4. 实战：支付场景改造

场景：
项目里有支付功能，现在支持 支付宝、微信
需求改造方向：

• 策略模式封装不同支付方式
• 以后加京东、银联，甚至“先交人情分”支付方式，都不动主要业务逻辑

💻 代码示例

// 策略接口
public interface PaymentStrategy {
    void pay(int amount);
}

// 支付宝策略
public class AliPayStrategy implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("💰 使用支付宝支付：" + amount + " 元");
    }
}

// 微信策略
public class WeChatPayStrategy implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("💰 使用微信支付：" + amount + " 元");
    }
}

// 环境类
public class PaymentContext {
    private PaymentStrategy strategy;

    public PaymentContext(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void payMoney(int amount) {
        strategy.pay(amount);
    }
}

// 测试
public class Main {
    public static void main(String[] args) {
        PaymentContext p1 = new PaymentContext(new AliPayStrategy());
        p1.payMoney(100);

        PaymentContext p2 = new PaymentContext(new WeChatPayStrategy());
        p2.payMoney(200);
    }
}

---

运行结果

💰 使用支付宝支付：100 元
💰 使用微信支付：200 元

不改 PaymentContext，就能轻松换支付方式，这就是策略模式的精髓。

---

5. 使用心得（个人感受版）

我认为策略模式的最大优势其实不是“消除 if-else”，而是让变化的东西不再到处乱跑。
在我自己的几个项目里：

• 新加一个策略类就能启用新功能，根本不动旧代码
• 策略切换非常灵活，测试也简单，可以单独对某个策略做单元测试

当然，我也踩过坑：

• 策略类很多的时候，类文件会爆炸（几十上百个策略类找得头大）
• 客户端代码如果要“自己选策略”，有时候业务会很乱，所以我后来配合工厂模式或配置驱动来管理

---

6. 什么时候用策略模式？

适合的场景：

• 功能有很多种实现方式
• 实现方式会一直变化、扩展
• 需要运行时灵活切换

不太适合：

• 只有一两种实现方式，而且几乎不变（搞那么多类纯属找事）

---

7. 总结

策略模式在代码重构的时候特别好用，它能帮我们把业务逻辑分成两部分：

1. 不变的部分：上下文环境框架
2. 可变的部分：各种具体策略实现

我的建议是：

• 如果分支逻辑过多且会变动，首选策略模式
• 策略选择逻辑，尽量不要放到业务代码里 → 用配置、工厂模式、依赖注入去做

---

💬 最后一句：
策略模式并不是万能的，但它会让你以后改需求的时候少掉很多头发。