策略模式：让代码更灵活、更优雅的“变形金刚”
在软件开发的浩瀚海洋中，我们会遇到这样的场景：一个算法或行为必须根据不同的条件进行切换。倘若处理不当，代码中会充斥着很多的的 `if-else` 或 `switch-case` 语句，导致逻辑臃肿、难以维护。
策略模式（Strategy Pattern） 正是解决这一问题的经典设计模式。这篇文章将深入解析策略模式的定义、核心结构、应用场景，并通过对比数据展示其带来的实际收益。
什么是策略模式？
1 定义
策略模式属于行为型设计模式。它定义了一系列算法，并将每一个算法封装起来，使它们可以相互替换。策略模式让算法独立于使用算法的客户。，策略模式就像是一个“工具箱”。你有一个任务（比如支付），这个任务有多种实现方法（支付宝、微信、信用卡）。策略模式允许你在运行时动态地选择使用哪种支付途径，而无需修改核心业务代码。
2 核心思想
- 封装变化：将易变的算法封装在独立的类中。
- 开闭原则（OCP）：对扩展开放，对修改关闭。新增一种策略只需增加一个新类，无需修改原有代码。
- 组合优于继承：经由组合对象的行为，而不是凭借继承来获得多样性。
策略模式结构
策略模式首要由三个角色组成：
| 角色 | 职责 | 类比 |
|---|---|---|
| Context（环境类） | 持有一个 Strategy 的引用，负责与具体策略交互。 | 顾客（决定使用哪种支付方式） |
| Strategy（策略接口） | 定义所有支持算法的公共接口。 | 支付接口（包含 `pay()` 方法） |
| ConcreteStrategy（具体策略类） | 实现 Strategy 接口，提供具体的算法实现。 | 支付宝支付、微信支付、信用卡支付 |
1 代码示例（Java 伪代码）
```java
// 1. 策略接口
interface PaymentStrategy {
void pay(double amount);
}
// 2. 具体策略：支付宝
class AlipayStrategy implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println("使用支付宝支付: " + amount);
}
}
// 3. 具体策略：微信支付
class WechatPayStrategy implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println("利用微信支付: " + amount);
}
}
// 4. 环境类
class OrderContext {
private PaymentStrategy strategy;
public OrderContext(PaymentStrategy strategy) {
this.strategy = strategy;
}
public void executePayment(double amount) {
strategy.pay(amount);
}
// 动态切换策略
public void setStrategy(PaymentStrategy strategy) {
this.strategy = strategy;
}
}
```
为什么需要策略模式？—— 痛点与解决方案
1 传统方式的弊端
在没有使用策略模式之前，我们会在一个类中利用很多的的条件判断：```java
public void processPayment(String type, double amount) {
if (type.equals("ALIPAY")) {
// 支付宝逻辑
} else if (type.equals("WECHAT")) {
// 微信逻辑
} else if (type.equals("CREDIT_CARD")) {
// 信用卡逻辑
} else {
// 默认逻辑
}
}
```
- 代码耦合度高：每次新增支付方式，都必须修改 `processPayment` 方法，违反开闭原则。
- 可读性差：随着条件分支增多，方法体变得冗长且难以阅读。
- 测试困难：每个分支都须要单独测试，维护成本高。
2 策略模式的优势
- 清晰的结构：每个策略类只关注自己的达成逻辑。
- 易于扩展：新增支付方式只需添加一个新类，无需修改现有代码。
- 运行时切换：可以在程序运行时动态选择算法。
数据对比：策略模式 vs 传统条件判断
为了更直观地展示策略模式的价值，我们经由以下表格对比两种实现方式在关键指标上的差异：
| 评估维度 | 传统条件判断（if-else/switch） | 策略模式 | 提升说明 |
|---|---|---|---|
| 新增策略成本 | 高：需修改核心方法，增加分支 | 低：只需新增一个类 | 符合开闭原则，降低回归风险 |
| 代码可读性 | 低：逻辑混杂，嵌套深 | 高：每个类职责单一 | 便于团队协作与维护 |
| 测试复杂度 | 高：需覆盖所有分支组合 | 低：每个策略独立测试 | 提高测试覆盖率与效率 |
| 运行时灵活性 | 无：逻辑在编译时确定 | 有：可动态切换策略 | 支持更复杂的业务场景 |
| 内存占用 | 低：所有逻辑在一个类中 | 略高：每个策略独立对象 | 现代 JVM 优化下差异可忽略 |
数据说明：以上对比基于典型的企业级应用开发场景。在实际项目中，当策略数量超过 3 种时，策略模式的优势开始显著体现。
应用场景
策略模式适用于以下场景：
1. 多个类仅在行为上不同：如不同国家的税收计算、不同物流公司的运费计算。
2. 须要避免使用复杂的条件语句：当 `if-else` 或 `switch` 分支过多时，考虑运用策略模式。
3. 算法对客户隐藏实现细节：客户只需知道“做什么”，无需知道“怎么做”。
4. 同一接口的不同实现须要动态切换：如图片压缩算法（JPEG、PNG、WebP）的选择。
潜在缺点与注意事项
尽管策略模式优点众多，但也需注意以下几点：
1. 客户端必须了解所有策略：客户端需要知道有哪些策略可用，并决定采用哪一个。这可以通过工厂模式结合策略模式来优化。
2. 类数量增加：每新增一个策略，就多一个类。对于小型项目，显得过度设计。
3. 策略之间的沟通限制：策略类之间默认是独立的，若需共享数据，可通过上下文类传递，但需谨慎设计。
总结
策略模式是软件设计中“解耦”思想的典范。它将算法的实现与使用分离，使代码更加灵活、可维护和可扩展。在面对多变的需求时，策略模式能够帮助我们构建出健壮且优雅的系统。
建议：在项目初期，若算法种类不多，可使用简单的条件判断；但随着业务复杂度提升，应及时引入策略模式，以避免代码腐化。记住：好的代码不是写出来的，而是设计出来的。
参考文献：- Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
- Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.