别再死记设计模式了！Java 21+ 把 Strategy Pattern 玩出花，这才是现代写法

首页

业界动态

热心网友

转载

2026-04-28

Strategy Pattern 从来没变，变的是 Ja va。从“类爆炸”到“函数式”，再到“类型驱动 + 模式匹配”，它已经从一种设计技巧，进化成了一种语言能力。

你写的不是设计模式，是“文件工厂”

还记得早期写策略模式的那种体验吗？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

先定义一个接口，然后跟着N个实现类。需求但凡有点风吹草动，类文件的数量就跟着水涨船高。五种策略？那就意味着五个类文件。想加点校验逻辑？得，五个文件都得改一遍。

从纯粹的设计角度看，这确实叫“优雅解耦”；但切换到工程实践的视角，这感觉更像是——一个高效的“文件膨胀器”。

如果今天还在沿用这套写法，那你的代码风格，可能还停留在Ja va 7的时代。

别再只会“接口 + N个实现类”的老套路

不妨先回顾一下最经典、最传统的写法。

public interface PaymentStrategy {
    void pay(double amount);
}
public class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid " + amount + " using Credit Card");
    }
}
public class PayPalPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid " + amount + " using PayPal");
    }
}

调用端通常是这样的：

public class PaymentService {
    private PaymentStrategy strategy;
    public PaymentService(PaymentStrategy strategy) {
        this.strategy = strategy;
    }
    public void process(double amount) {
        strategy.pay(amount);
    }
}

平心而论，这套写法本身没有错，它完美体现了面向接口编程的思想。但问题也显而易见：

类爆炸：策略数量与类文件数量线性增长。
修改成本高：任何公共逻辑的调整都可能需要修改多个文件。
逻辑分散：相同领域的逻辑散落在各个类中，难以形成整体视图。
可读性下降：随着策略增多，在代码库中定位和理解具体逻辑变得越来越困难。

别再只会用 Ja va 8 Lambda 的“半升级版本”

Ja va 8引入Lambda表达式后，很多人觉得已经迈向了“现代化”：

PaymentStrategy creditCard = amount ->
        System.out.println("Paid " + amount + " using Credit Card");
PaymentStrategy paypal = amount ->
        System.out.println("Paid " + amount + " using PayPal");

看起来确实清爽了不少，至少文件数量降下来了。但深究下去，核心问题依然存在：

没有类型约束：策略本质上还是一个函数对象，缺乏丰富的类型信息。
复杂逻辑难维护：当策略逻辑变得复杂时，内联的Lambda会变得臃肿且难以测试。
扩展性依旧有限：增加新的策略类型，仍然需要手动修改调用处的逻辑。

可以说，这只是利用新语法做了“文件减肥”，并没有触及策略模式“模型”的升级。

别再忽略 Ja va 17 的 sealed + record 带来的结构升级

真正的转折点，其实是从Ja va 17开始的。sealed classes/interfaces和record这两个特性，为我们重新构思策略模式提供了全新的建筑材料。

我们可以用sealed interface来严格限定策略的家族成员，用record来清晰表达策略所携带的数据结构。

// 定义策略的密封接口，明确声明允许的实现
package com.icoderoad.strategy;
public sealed interface PaymentStrategy
        permits CreditCard, PayPal {}

// 策略一：信用卡支付，用record封装卡号数据
package com.icoderoad.strategy;
public record CreditCard(String cardNumber) implements PaymentStrategy {}

// 策略二：PayPal支付，用record封装邮箱数据
package com.icoderoad.strategy;
public record PayPal(String email) implements PaymentStrategy {}

这样一来，策略不再仅仅是封装一个“行为”的抽象，而是进化为“数据 + 类型”的强组合。每种策略是什么，能携带什么数据，在编译期就一清二楚。

别再写 if-else，Ja va 21 的 pattern matching 才是核心玩法

到了Ja va 21，随着模式匹配for switch的成熟，策略模式终于完成了它的终极进化。处理逻辑可以变得如此集中和直观：

package com.icoderoad.strategy;
public class PaymentProcessor {
    public static void process(PaymentStrategy strategy, double amount) {
        switch (strategy) {
            case CreditCard cc ->
                 System.out.println("Paid " + amount + " with card: " + cc.cardNumber());
            case PayPal pp ->
                 System.out.println("Paid " + amount + " via PayPal: " + pp.email());
        }
    }
}

这种写法带来的变化是本质性的：

不再需要N个类分散逻辑：所有策略的分支处理集中在一处，一目了然。
所有策略集中在一个可控范围：阅读和维护者无需在多个文件间跳转。
编译期保证类型安全：switch表达式会检查是否覆盖了所有sealed接口的许可类型。
代码结构更加线性、可读：逻辑流是线性的，极大地降低了认知负担。

别再把策略模式当“类设计”，它本质是“分支控制”

这里存在一个普遍的误解。策略模式的核心目的，从来不是为了展示多态技巧，它的本质是：

在运行时选择不同逻辑路径

现代Ja va语法给了我们更直接、更声明式的方式来表达这一意图：

public static void process(PaymentStrategy strategy, double amount) {
    switch (strategy) {
        case CreditCard cc -> handleCard(cc, amount);
        case PayPal pp -> handlePayPal(pp, amount);
    }
}

对比旧时代的写法，优势立现：