## 01、痛点

我是老李，一个写了十几年 Java 的后端。最近接手一个订单系统，里面有个“订单通知服务”。代码历史是这样的：第一版只支持短信，后来加了邮件，再后来企业微信、钉钉、站内信全来了。

最开始代码大概长这样：

```java
public void sendNotify(Order order) {
    if ("SMS".equals(order.getNotifyType())) {
        // 发短信
    } else if ("EMAIL".equals(order.getNotifyType())) {
        // 发邮件
    } else if ("WECHAT".equals(order.getNotifyType())) {
        // 发企业微信
    } else if ("DINGTALK".equals(order.getNotifyType())) {
        // 发钉钉
    } else if ("INBOX".equals(order.getNotifyType())) {
        // 发站内信
    } else {
        log.warn("unknown notify type: {}", order.getNotifyType());
    }
}
```

再往后，逻辑膨胀。每个分支里不只发送，还包括参数校验、模板渲染、开关判断、重试、埋点、风控检查。方法从 30 行涨到 600 多行。

新增一个渠道，就要在同一个方法里继续加 else if，同时要改：
- 渠道枚举
- 配置类
- 参数校验
- 监控埋点
- 单元测试

每次改动都像在已经倾斜的积木塔上再放一块。新人第一次打开这个类，通常只敢看，不敢动；老手改完一个分支，心里也没底。

传统写法结构：

```
OrderNotifyService
|
+-- if 短信
+-- else if 邮件
+-- else if 企业微信
+-- else if 钉钉
+-- else if 站内信
```

> 锐评：一个只有两个分支的业务，硬塞进去三个接口、四个抽象类，那不叫设计模式，那叫给自己增加就业机会。

但反过来，当系统已经长成上面这个样子时，问题已经不是“代码不够高级”，而是变化开始失控。

设计模式真正解决的，从来不是让代码看上去更漂亮，而是让你下次改需求时，不用在旧代码上反复开刀。

## 02、是什么

先不背定义。

设计模式，本质上是软件开发中反复出现的一类问题的成熟解法。

它不是代码模板，也不是必须套用的公式，而是一种“职责如何拆、变化放在哪里”的思考方式。

从工程视角看，它解决三个层次的问题：

第一层：代码复用。
第二层：隔离变化。
第三层：管理复杂度。

GoF 把 23 种设计模式分成三大类：创建型、结构型、行为型。这个分类有用，但不值得一开始就死记。

我更建议建立一个更实际的问题映射：

```
代码坏味道                         可能关联的模式
--------------------------------------------------
if / else 按类型变化                策略模式
流程基本一样，部分步骤变化          模板方法
多个处理节点顺序执行                责任链
第三方接口长得完全不一样            适配器
对象创建越来越复杂                  工厂模式
对象状态不同导致行为不同            状态模式
```

本文重点聊策略模式。

策略模式的核心思想是：定义一组算法，把它们封装起来，让它们之间可以相互替换。

它不是四个 Java 文件这么简单。它由三个角色组成：

```
Strategy          策略接口
ConcreteStrategy  具体策略实现
Context           持有策略并使用策略的上下文
```

以支付为例：

```
PaymentStrategy
      |
      +-- AlipayPaymentStrategy
      +-- WechatPaymentStrategy
      +-- BankCardPaymentStrategy
      |
PaymentContext / PaymentFactory
```

这里的算法，不一定是排序、加密这类纯算法。在业务系统里，“支付宝支付”“微信支付”“银行卡支付”就是一组可替换的业务算法。

## 03、为什么

很多开发者学过策略模式，背过定义，画过类图，但一到真实项目就不会用。原因通常不是笨，而是三个误区。

误区一：先记模式，再找地方套。

拿到需求先想“这里能不能用个设计模式”，而不是先看变化点在哪里。结果往往是模式很标准，问题没解决。

误区二：看到 if / else 就认为必须上策略模式。

if / else 不是原罪。两个稳定分支如果永远只有两个，直接写 if 反而最直观。为了消除 if 而硬上策略，只会把简单代码复杂化。

误区三：抽象层越多，架构越高级。

抽象不是目的，降低变化成本才是。抽象层多不代表设计好，只代表读代码的人要跳更多次。

那什么时候值得上策略模式？可以用下面五个标准判断：

1. 变化是否真实存在？
2. 变化是否会持续增加？
3. 修改是否频繁影响旧逻辑？
4. 多个实现是否存在稳定公共结构？
5. 引入模式后，理解成本是否低于原来的维护成本？

简单判断公式：

```
模式收益 = 未来变化成本降低 - 当前抽象复杂度增加
```

如果值明显为正，才值得做。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。

设计模式不是减少代码，而是降低未来修改代码的风险。

## 04、架构

设计模式实践地图，不应该按 GoF 三大类背，而应该按开发问题分类。

```
变化类型一：对象怎么创建？
→ 工厂 / 建造者

变化类型二：多个实现怎么切换？
→ 策略模式

变化类型三：流程怎么复用？
→ 模板方法

变化类型四：多个节点怎么串起来？
→ 责任链

变化类型五：外部系统怎么接进来？
→ 适配器

变化类型六：功能怎么动态叠加？
→ 装饰器

变化类型七：状态不同怎么改变行为？
→ 状态模式
```

策略模式在 Spring 项目中，已经不是 GoF 书里那种“接口 + 实现 + Context 手动 new”的写法，而是：

```
需求变化
   ↓
识别变化点：支付渠道持续增加
   ↓
职责拆分：支付逻辑独立
   ↓
模式选择：策略模式 + 工厂
   ↓
接口稳定：PaymentStrategy
   ↓
实现扩展：AlipayStrategy、WechatStrategy、BankCardStrategy
```

典型的 Spring 工程化结构：

```
PaymentController / PaymentService
           |
           v
   PaymentStrategyFactory
           |
       Map<PayType, PaymentStrategy>
           |
   +-------+-------+--------+
   |           |            |
Alipay      Wechat        BankCard
Strategy    Strategy      Strategy
```

可以看到，策略模式和工厂模式经常一起出现：策略负责算法替换，工厂负责策略路由。

## 05、实战

下面用一个支付渠道重构，完整走一遍从失控到可控的过程。

### 一、业务场景

订单系统需要支持支付宝、微信、银行卡三种支付方式。需求是：调用方传入支付类型和金额，系统完成对应渠道的支付发起。

### 二、第一版代码

最直观的写法：

```java
public class PaymentService {

    public PaymentResult pay(PayRequest request) {
        if ("ALIPAY".equals(request.getPayType())) {
            // 校验订单
            // 调用支付宝 API
            // 解析响应
            // 写支付日志
            // 埋点
            return alipayPay(request);
        } else if ("WECHAT".equals(request.getPayType())) {
            // 校验订单
            // 调用微信 API
            // 解析响应
            // 写支付日志
            // 埋点
            return wechatPay(request);
        } else if ("BANK_CARD".equals(request.getPayType())) {
            // 校验订单
            // 调用银行卡 API
            // 解析响应
            // 写支付日志
            // 埋点
            return bankCardPay(request);
        }
        throw new IllegalArgumentException("unsupported pay type");
    }
}
```

### 三、代码开始失控

后来新增了“京东支付”“云闪付”“苹果支付”，每次加一个渠道，这个方法就要继续增加 else if。更麻烦的是：

- 每个分支都有重复的校验、日志、埋点。
- 一个渠道的异常如果处理不好，会影响到整个方法。
- 单元测试没法只测某一个渠道，必须 mock 所有分支。
- 业务代码和渠道实现耦合在一个类里，改动互相污染。

此时，if / else 已经不只是条件判断，它把“支付类型路由”和“具体支付逻辑”搅在了一起。

### 四、模式重构

先定义策略接口：

```java
public interface PaymentStrategy {
    PayType getPayType();
    PaymentResult pay(PayRequest request);
}
```

每个支付渠道实现这个接口：

```java
@Component
public class AlipayPaymentStrategy implements PaymentStrategy {

    @Override
    public PayType getPayType() {
        return PayType.ALIPAY;
    }

    @Override
    public PaymentResult pay(PayRequest request) {
        // 只做支付宝相关逻辑
        return new PaymentResult(...);
    }
}

@Component
public class WechatPaymentStrategy implements PaymentStrategy {
    // ...
}

@Component
public class BankCardPaymentStrategy implements PaymentStrategy {
    // ...
}
```

支付类型枚举：

```java
public enum PayType {
    ALIPAY,
    WECHAT,
    BANK_CARD
}
```

再写一个策略工厂，利用 Spring 自动注入所有策略实现：

```java
@Component
public class PaymentStrategyFactory {

    private final Map<PayType, PaymentStrategy> strategyMap;

    @Autowired
    public PaymentStrategyFactory(List<PaymentStrategy> strategies) {
        strategyMap = strategies.stream()
                .collect(Collectors.toMap(PaymentStrategy::getPayType, s -> s));
    }

    public PaymentStrategy getStrategy(PayType payType) {
        PaymentStrategy strategy = strategyMap.get(payType);
        if (strategy == null) {
            throw new IllegalArgumentException("unsupported pay type: " + payType);
        }
        return strategy;
    }
}
```

原来的 PaymentService 瘦身成：

```java
@Service
public class PaymentService {

    private final PaymentStrategyFactory strategyFactory;

    public PaymentService(PaymentStrategyFactory strategyFactory) {
        this.strategyFactory = strategyFactory;
    }

    public PaymentResult pay(PayRequest request) {
        PaymentStrategy strategy = strategyFactory.getStrategy(request.getPayType());
        return strategy.pay(request);
    }
}
```

如果不想额外维护工厂类，也可以直接注入 Map：

```java
@Service
public class PaymentService {

    private final Map<String, PaymentStrategy> strategyMap;

    @Autowired
    public PaymentService(Map<String, PaymentStrategy> strategyMap) {
        this.strategyMap = strategyMap;
    }

    public PaymentResult pay(PayRequest request) {
        String beanName = request.getPayType().name();
        PaymentStrategy strategy = strategyMap.get(beanName);
        if (strategy == null) {
            throw new IllegalArgumentException("unsupported pay type");
        }
        return strategy.pay(request);
    }
}
```

这种方式下，Spring 会把 bean name 作为 key 注入 Map。比如 `alipayPaymentStrategy` 对应支付宝。优点是少一个类，缺点是把路由 key 直接绑定到 bean 命名，可读性略差。

### 五、结构变化

改造前：

```
PaymentService
   |
   +-- if ALIPAY
   +-- else if WECHAT
   +-- else if BANK_CARD
```

改造后：

```
PaymentService
   |
   v
PaymentStrategyFactory
   |
   v
PaymentStrategy 接口
   |           |           |
Alipay      Wechat      BankCard
```

### 六、收益

- 新增支付方式，只需新增一个 `PaymentStrategy` 实现类，不需要修改 `PaymentService`。
- 每个渠道的校验、参数、异常、日志都内聚在各自的策略里。
- 单元测试可以只测试某一个策略，不用关心其他渠道。
- 代码结构从“一个类管所有渠道”，变成“一个类管一条渠道”。

### 七、代价

- 类数量增加：一个渠道一个类，再加接口和工厂。
- 阅读链路变长：原来直接看一个方法，现在要跳接口、跳工厂、跳实现。
- 对新人来说，需要先理解“策略模式 + 工厂模式 + Spring 注入”三者协作。

### 八、什么时候不要用

如果支付渠道只有两个，而且未来三年都不会新增，别拆。直接写 if / else，或者用枚举内部方法都可以。

> 锐评：一个只有两种支付方式，而且未来三年都不会增加的系统，硬拆十几个类，解决的不是扩展性问题，而是阅读理解问题。

策略模式口诀：

“不是消灭 if，而是隔离持续变化的 if。”

策略 + 工厂组合时，还要注意一个常见坑：策略的 `getPayType` 返回类型最好使用枚举，不要用魔法字符串，否则容易出现拼写错误导致的幽灵分支。

另外，如果策略内部还有大量重复的骨架流程，比如“参数校验 -> 调用渠道 -> 解析响应 -> 落库”，可以考虑把模板方法引入，但这里不再展开。

## 06、洞见

会使用策略模式，不等于会判断该不该用。

设计模式背后真正值得掌握的能力，是识别变化、隔离变化、管理修改半径。

洞见一：设计模式真正关注的是“变化”，不是“类”。

类多是结果，不是目标。真正的目标是把变化点收口到一个相对稳定的接口后面。

洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。

第一次写支付 if / else 没有错。错的是第二次、第三次新增渠道时，还在原方法上继续堆条件。

洞见三：设计模式最重要的价值是降低修改半径。

所谓修改半径，就是改一个需求，你需要动多少处代码。策略模式把“新增渠道”的修改半径，从一个几千行服务类，缩小到新增一个类。

洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。

很多项目不是设计不足，而是抽象过度。十个类能解决的问题，被拆成三十个类和二十个接口，最后维护成本反而更高。

洞见五：很多 Spring 框架设计本身就是设计模式的大型实践。

- Spring BeanFactory → 工厂模式
- ApplicationListener → 观察者模式
- JdbcTemplate → 模板方法
- HandlerInterceptor → 责任链思想
- AOP → 代理思想

理解了框架中的模式，再回头看业务代码，很多抽象会自然很多。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

不要一上来就背 23 种模式。推荐一个三阶段路径。

第一阶段：先认识 5 个最常用模式。

策略、工厂、模板方法、责任链、适配器。

第二阶段：从自己的项目里找坏味道。

每天找一个：
- 大 if / else
- 重复流程
- 第三方接口污染
- 复杂对象创建
- 状态判断

第三阶段：尝试重构。

每次重构都回答五个问题：

1. 变化点是什么？
2. 不使用模式会怎样？
3. 使用模式增加了什么复杂度？
4. 下一次新增需求，需要修改几个地方？
5. 新人是否更容易理解？

七天实践计划：

- Day 1：找一个超过 5 个分支的 if / else。
- Day 2：用策略模式重构它。
- Day 3：找一段重复的业务流程。
- Day 4：尝试用模板方法抽公共部分。
- Day 5：找一个第三方接口封装。
- Day 6：用适配器隔离外部字段。
- Day 7：重新评估：哪些重构其实没有必要？

补充一句：重构一定要结合项目真实情况。不要为了完成“学习任务”而把线上系统过度设计。你可以先在测试分支或新模块里试验，确认收益后再逐步推广。

## 08、小结

“设计模式不是为了让代码看起来高级，而是为了让下一次需求变化时，你不用推倒重来。”

真正值得学习的不是 23 个名字，而是看到变化、识别变化、隔离变化的能力。

策略模式只是这套能力的一个入口。它让你看到：原来一坨 if / else 背后，其实是一种可被封装、可被替换的算法变化。

如果读完这篇文章，你少写了一个 500 行 if / else，这篇文章就算没有白写。

## 09、链接与概念说明

- GoF：指 Gang of Four，即《Design Patterns: Elements of Reusable Object-Oriented Software》一书的四位作者，该书中提出了 23 种经典设计模式。
- 创建型模式：关注对象怎么创建，如工厂、建造者。
- 结构型模式：关注类与对象如何组合成更大结构，如适配器、装饰器。
- 行为型模式：关注对象之间如何协作和分配职责，如策略、观察者、责任链。
- SOLID 原则与设计模式关系：SOLID 是面向对象设计的五个基本原则，设计模式多数是这些原则的具体落地。策略模式主要体现开闭原则和单一职责原则。
- 开闭原则：对扩展开放，对修改关闭。策略模式通过新增实现类来扩展行为，而不是修改已有分支逻辑，因此常和设计模式一起出现。

推荐继续阅读：

- 《Design Patterns: Elements of Reusable Object-Oriented Software》，GoF 合著，经典但偏理论。
- 《Refactoring: Improving the Design of Existing Code》，Martin Fowler，适合配合现实重构。
- Spring Framework 官方文档，重点看 IoC 容器、Bean 生命周期、事件机制等章节。

我是老李，一个写了十几年 Java 的后端。最近接手一个订单系统，里面有个“订单通知服务”。代码历史是这样的：第一版只支持短信，后来加了邮件，再后来企业微信、钉钉、站内信全来了。

《设计模式军体拳第22招》 策略模式 Strategy——把变化的算法独立封装起来

从订单支付渠道的一坨 if/else 出发，讲透策略模式如何结合 Spring Bean 自动注册、Map 路由与工厂模式，以及什么时候不该用。

架构师

编程语言

后端

架构设计

策略模式实战指南：通过支付渠道重构案例，深入解析if/else失控场景下的代码改造方案。涵盖策略模式核心原理、Spring工厂整合技巧、五维判断标准，助你识别变化点、隔离变化、降低修改半径，实现从大if/else到高扩展性架构的平滑演进。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第22招》 策略模式 Strategy——把变化的算法独立封装起来-腾讯云开发者社区-腾讯云

《设计模式军体拳第22招》策略模式 Strategy——把变化的算法独立封装起来

《设计模式军体拳第22招》策略模式 Strategy——把变化的算法独立封装起来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第22招》 策略模式 Strategy——把变化的算法独立封装起来

《设计模式军体拳第22招》 策略模式 Strategy——把变化的算法独立封装起来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第22招》策略模式 Strategy——把变化的算法独立封装起来

《设计模式军体拳第22招》策略模式 Strategy——把变化的算法独立封装起来