Java 策略模式：高可扩展架构的设计密钥与工程实践-CSDN博客

本文链接：https://blog.csdn.net/qq_20294455/article/details/148128924

一、策略模式的核心思想与本质

在软件开发的漫长演进历程中，算法的动态切换与封装一直是备受关注的设计难题。当系统中存在多种不同算法实现，且需要在运行时灵活切换这些算法时，传统的条件判断方式会导致代码臃肿、可维护性差。策略模式（Strategy Pattern）正是为解决这类问题而生的经典设计模式，它属于行为型模式家族，其核心思想是将算法的定义与使用分离。

策略模式的本质可以概括为 "封装算法族，实现策略的自由切换"。它通过将一系列算法封装成独立的策略类，使得这些策略类可以相互替换，从而让算法的变化不会影响到使用算法的客户端。这种设计遵循了开闭原则（对扩展开放，对修改关闭），将具体的算法实现从客户端代码中解耦出来，客户端只需与策略接口交互，而无需关心具体的策略实现细节。

从现实生活中举例，比如出行方式的选择：有人喜欢开车、有人选择地铁、有人习惯骑自行车。每种出行方式就是一个具体的策略，而选择出行方式的人就是客户端。客户端可以根据不同的场景（如天气、距离、时间等）动态选择不同的出行策略，而无需修改客户端本身的逻辑。这与策略模式在软件设计中的应用场景异曲同工。

二、策略模式的结构与角色

策略模式包含三个核心角色，它们共同构成了一个完整的策略体系，确保算法的封装与灵活切换。

（一）策略接口（Strategy）

策略接口是所有具体策略类的公共接口，它定义了策略类的行为规范，封装了算法的抽象方法。在 Java 中，通常用接口来实现策略接口，例如定义一个支付策略接口：

java

public interface PaymentStrategy {
    void pay(double amount);
}

这个接口声明了支付策略的核心方法pay，具体的支付方式（如支付宝支付、微信支付、银联支付等）都需要实现这个接口，确保它们具有一致的对外行为。策略接口的存在使得客户端可以通过统一的接口来调用不同的策略，实现了客户端与具体策略的解耦。

（二）具体策略类（ConcreteStrategy）

具体策略类是策略接口的具体实现，每个具体策略类封装了一种具体的算法或行为。例如，支付宝支付策略类可以这样实现：

java

public class AlipayStrategy implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("使用支付宝支付：" + amount + "元");
        // 具体的支付宝支付逻辑
    }
}

同样，微信支付策略类实现相同的接口，只是具体的支付逻辑不同。每个具体策略类都独立地完成特定的算法，它们之间可以相互替换，客户端可以根据需要选择不同的具体策略类来完成相应的功能。具体策略类的存在使得算法的扩展变得非常容易，当需要新增一种支付方式时，只需新增一个实现策略接口的具体策略类即可，无需修改现有的代码。

（三）上下文类（Context）

上下文类是策略模式的核心协调者，它持有一个策略接口的引用，负责与客户端交互，委托策略对象执行相应的算法。上下文类通常提供一个方法来设置策略对象，以便在运行时动态切换策略。例如：

java

public class PaymentContext {
    private PaymentStrategy paymentStrategy;

    public void setPaymentStrategy(PaymentStrategy strategy) {
        this.paymentStrategy = strategy;
    }

    public void pay(double amount) {
        paymentStrategy.pay(amount);
    }
}

客户端通过上下文类来使用策略，而不是直接与具体策略类交互。上下文类屏蔽了具体策略类的差异，客户端只需与上下文类打交道，通过设置不同的策略对象来实现不同的算法行为。这样，客户端代码就变得简洁且易于维护，同时也符合依赖倒置原则，即高层模块依赖抽象（策略接口）而不是具体实现（具体策略类）。

三、策略模式的实现步骤

（一）定义策略接口

首先，根据具体的业务场景，确定策略所需要具备的功能，定义一个统一的策略接口。这个接口应包含所有具体策略类都需要实现的方法。例如，在电商平台的促销策略中，策略接口可能定义计算折扣的方法：

java

public interface PromotionStrategy {
    double calculateDiscount(double originalPrice);
}

（二）实现具体策略类

接下来，针对每一种具体的算法或行为，创建实现策略接口的具体策略类。每个具体策略类都要实现策略接口中定义的方法，完成具体的业务逻辑。比如，满减促销策略类和打折促销策略类：

java

public class FullReductionStrategy implements PromotionStrategy {
    private double fullAmount;
    private double reductionAmount;

    public FullReductionStrategy(double fullAmount, double reductionAmount) {
        this.fullAmount = fullAmount;
        this.reductionAmount = reductionAmount;
    }

    @Override
    public double calculateDiscount(double originalPrice) {
        if (originalPrice >= fullAmount) {
            return originalPrice - reductionAmount;
        }
        return originalPrice;
    }
}

public class DiscountStrategy implements PromotionStrategy {
    private double discountRate;

    public DiscountStrategy(double discountRate) {
        this.discountRate = discountRate;
    }

    @Override
    public double calculateDiscount(double originalPrice) {
        return originalPrice * discountRate;
    }
}

（三）创建上下文类

然后，设计一个上下文类，该类用于管理策略对象，提供设置策略和执行策略的方法。上下文类通常在构造时可以接受一个策略对象，或者在运行时动态设置策略对象。例如：

java

public class PromotionContext {
    private PromotionStrategy promotionStrategy;

    public PromotionContext(PromotionStrategy strategy) {
        this.promotionStrategy = strategy;
    }

    public void setPromotionStrategy(PromotionStrategy strategy) {
        this.promotionStrategy = strategy;
    }

    public double applyPromotion(double originalPrice) {
        return promotionStrategy.calculateDiscount(originalPrice);
    }
}

（四）客户端使用

最后，客户端通过上下文类来使用策略模式。客户端首先创建具体的策略对象，然后将其设置到上下文类中，通过上下文类调用相应的策略方法。例如：

java

public class Client {
    public static void main(String[] args) {
        // 创建满减策略，满200减50
        PromotionStrategy fullReduction = new FullReductionStrategy(200, 50);
        PromotionContext context = new PromotionContext(fullReduction);
        double price = context.applyPromotion(300);
        System.out.println("满减后的价格：" + price); // 输出250

        // 切换为打折策略，打8折
        PromotionStrategy discount = new DiscountStrategy(0.8);
        context.setPromotionStrategy(discount);
        price = context.applyPromotion(300);
        System.out.println("打折后的价格：" + price); // 输出240
    }
}

通过以上四个步骤，就完成了策略模式的实现。客户端可以在运行时动态切换不同的策略，而无需修改客户端代码，体现了策略模式的灵活性和可扩展性。

四、策略模式的优缺点分析

（一）显著优点

开闭原则的完美体现：策略模式将具体的算法实现封装在独立的策略类中，当需要新增或修改算法时，只需新增或修改具体的策略类，而无需修改客户端代码和上下文类，符合开闭原则，极大地提高了系统的可维护性和可扩展性。
算法自由切换：客户端可以在运行时根据实际需求动态切换不同的策略对象，从而选择不同的算法来完成任务。这种灵活性使得系统能够更好地适应不同的业务场景和需求变化。
避免多重条件判断：在传统的实现方式中，通常会使用大量的条件判断语句（如if-else或switch-case）来选择不同的算法，这会导致代码臃肿且难以维护。策略模式通过将算法封装在策略类中，消除了这些条件判断语句，使代码更加简洁清晰。
责任分离：策略模式将算法的定义与使用分离，具体策略类负责算法的实现，上下文类负责算法的调用，客户端只需关注如何选择策略，这种职责分离使得系统的结构更加清晰，各部分的功能更加明确。

（二）潜在缺点

客户端需要了解策略类：虽然策略模式将算法的实现细节封装在策略类中，但客户端在使用时需要知道有哪些具体的策略类可供选择，并负责创建和管理策略对象。如果策略类的数量较多，可能会增加客户端的使用难度。
策略类数量增多：每一种具体的算法都需要对应一个具体的策略类，当算法种类较多时，会导致策略类的数量急剧增加，增加了系统的类管理成本。
策略之间的依赖问题：如果不同的策略类之间存在复杂的依赖关系，或者需要共享某些状态数据，策略模式的实现可能会变得复杂，需要额外的处理来解决这些问题。

（三）适用场景

多个相关的算法族：当系统中存在多个功能相似但具体实现不同的算法，并且这些算法可以独立变化时，适合使用策略模式。例如，不同的排序算法、不同的加密算法、不同的支付方式等。
需要动态切换算法：如果客户端需要在运行时根据不同的条件动态选择不同的算法来执行，策略模式可以方便地实现这种动态切换，而无需修改客户端代码。
避免使用多重条件判断：当代码中存在大量的条件判断语句来选择不同的算法实现时，使用策略模式可以将这些条件判断替换为对策略对象的动态调用，使代码更加简洁易维护。
算法需要独立扩展：如果希望在不修改现有代码的情况下，方便地新增一种算法实现，策略模式提供了良好的扩展机制，只需新增一个具体策略类即可。

五、策略模式在 Java 中的典型应用

（一）集合框架中的 Comparator 接口

Java 集合框架中的Comparator接口是策略模式的一个典型应用。Comparator接口定义了对象的比较策略，不同的具体比较器实现类（如按升序比较、按降序比较、按自定义规则比较等）就是具体的策略类。当我们需要对集合中的元素进行排序时，可以通过Arrays.sort()或Collections.sort()方法，并传入不同的Comparator对象来实现不同的排序策略。

例如，对一个整数列表进行升序和降序排序：

java

List<Integer> numbers = Arrays.asList(3, 1, 4, 1, 5, 9);

// 升序排序策略
Comparator<Integer> ascendingComparator = (a, b) -> a - b;
numbers.sort(ascendingComparator);
System.out.println("升序排序：" + numbers); // 输出[1, 1, 3, 4, 5, 9]

// 降序排序策略
Comparator<Integer> descendingComparator = (a, b) -> b - a;
numbers.sort(descendingComparator);
System.out.println("降序排序：" + numbers); // 输出[9, 5, 4, 3, 1, 1]

在这里，ascendingComparator和descendingComparator就是具体的策略对象，numbers.sort()方法相当于上下文类，通过接受不同的比较策略来实现不同的排序行为。

（二）Swing 中的布局管理器

Swing 中的布局管理器也是策略模式的应用实例。LayoutManager接口定义了组件在容器中的布局策略，具体的布局管理器如FlowLayout、BorderLayout、GridLayout等都是具体的策略类。每个容器（如JPanel）可以通过设置不同的布局管理器来改变组件的排列方式，这相当于在运行时动态切换布局策略。

例如，创建一个面板，先使用流式布局，再切换为边界布局：

java

JPanel panel = new JPanel();

// 使用流式布局策略
panel.setLayout(new FlowLayout());
// 添加组件...

// 切换为边界布局策略
panel.setLayout(new BorderLayout());
// 添加组件...

通过这种方式，容器可以灵活地选择不同的布局策略，而无需修改容器本身的代码，体现了策略模式的灵活性。

（三）Spring 框架中的策略模式应用

在 Spring 框架中，策略模式也有广泛的应用。例如，MessageConverter接口用于将消息转换为不同的格式，不同的实现类如StringMessageConverter、MappingJackson2MessageConverter等就是具体的策略类。Spring 的RestTemplate在发送和接收消息时，可以根据需要配置不同的MessageConverter策略，实现对不同媒体类型的支持。

此外，Spring 的事务管理中，不同的事务传播行为（如PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW等）也可以看作是不同的策略，事务管理器根据这些策略来控制事务的执行流程。

六、策略模式与其他设计模式的结合

（一）策略模式与工厂模式的结合

在实际开发中，策略模式常常与工厂模式结合使用，以简化客户端对策略对象的创建和管理。策略工厂可以根据给定的条件或参数，动态地创建相应的策略对象，客户端无需直接实例化具体策略类，只需与策略工厂交互即可。

例如，创建一个支付策略工厂：

java

public class PaymentStrategyFactory {
    public static PaymentStrategy createPaymentStrategy(String strategyType) {
        switch (strategyType) {
            case "alipay":
                return new AlipayStrategy();
            case "wechat":
                return new WechatPayStrategy();
            case "unionpay":
                return new UnionPayStrategy();
            default:
                throw new IllegalArgumentException("不支持的支付策略类型");
        }
    }
}

客户端通过工厂方法获取策略对象：

java

PaymentStrategy strategy = PaymentStrategyFactory.createPaymentStrategy("alipay");
PaymentContext context = new PaymentContext(strategy);
context.pay(100);

这样，客户端就无需知道具体策略类的类名和实例化过程，降低了客户端与具体策略类的耦合度，同时也方便了策略对象的管理和扩展。

（二）策略模式与状态模式的区别与联系

策略模式和状态模式都属于行为型模式，它们在结构上有一定的相似性，都包含一个接口和多个具体实现类。但它们的设计目的和应用场景有所不同：

策略模式：客户端可以在运行时动态选择不同的策略对象，策略对象之间是平等的，客户端知道所有的策略类型，并主动选择使用哪种策略。策略模式的重点在于算法的封装和自由切换，客户端主动控制策略的选择。
状态模式：对象的行为依赖于其内部状态，当状态发生改变时，对象的行为也会随之改变。状态模式中，状态的切换是由对象内部的状态逻辑自动控制的，客户端无需知道具体的状态类，只需要与上下文对象交互即可。状态模式的重点在于对象状态的管理和基于状态的行为变化。

虽然两者有区别，但在某些情况下可以结合使用。例如，一个对象的不同状态对应不同的策略，此时可以在状态模式中使用策略模式来封装状态相关的行为。

（三）策略模式与责任链模式的结合

策略模式和责任链模式可以结合使用来处理复杂的业务逻辑。责任链模式将请求的处理者连成一条链，请求沿着链传递，直到有一个处理者处理它。而策略模式可以为每个处理者提供不同的处理策略，使得处理者可以根据不同的策略来处理请求。

例如，在一个审批流程中，每个审批节点可以有不同的审批策略（如根据金额大小选择不同的审批人），可以使用策略模式来封装这些审批策略，同时使用责任链模式来构建审批流程的链条，每个节点使用相应的审批策略来处理审批请求。

七、策略模式的最佳实践与注意事项

（一）合理划分策略粒度

在设计策略类时，需要合理划分策略的粒度。策略类既不能过于细化（导致策略类数量过多），也不能过于粗糙（导致策略类功能复杂）。应该根据具体的业务需求，将具有相似功能或可以独立变化的算法封装为一个策略类。例如，在支付场景中，将支付宝支付、微信支付、银联支付分别作为独立的策略类是合理的，而如果将支付和退款操作合并为一个策略类，则可能导致策略类功能过于复杂，不符合单一职责原则。

（二）使用组合代替继承

策略模式通过组合的方式将策略对象注入到上下文类中，而不是通过继承来实现算法的变化。这种方式比继承更加灵活，因为继承是静态的，一旦子类继承了父类的算法，就无法在运行时动态改变；而组合是动态的，可以在运行时随时替换策略对象，实现算法的动态切换。因此，在设计时应优先使用组合而非继承。

（三）处理策略之间的公共行为

如果多个具体策略类之间存在公共的行为或数据，可以将这些公共部分提取到一个抽象策略类中，让具体策略类继承这个抽象策略类。抽象策略类可以实现策略接口的部分公共方法，提供默认的实现，减少代码冗余。例如，如果所有的支付策略都需要记录支付日志，可以在抽象策略类中实现记录日志的方法，具体策略类只需专注于实现具体的支付逻辑。

（四）注意线程安全问题

如果策略对象是无状态的（即不包含成员变量，或者成员变量是不可变的），那么它们可以被多个客户端共享，无需考虑线程安全问题。但如果策略对象包含状态（即有成员变量），则需要注意线程安全，可能需要为每个客户端创建独立的策略对象，或者在策略类中实现线程安全的机制。

（五）文档与注释

在使用策略模式时，应提供清晰的文档和注释，说明每个策略类的功能、适用场景以及策略接口的定义。这有助于团队成员理解代码结构，方便后续的维护和扩展。特别是当策略类较多时，良好的文档和注释可以提高开发效率，减少沟通成本。

八、总结与展望

策略模式作为一种经典的行为型设计模式，通过封装算法族并实现策略的自由切换，有效地解决了软件开发中算法动态切换和可维护性的问题。它体现了开闭原则、依赖倒置原则和单一职责原则，是提高代码质量和系统灵活性的重要工具。

在 Java 开发中，策略模式的应用场景非常广泛，从基础的集合框架到复杂的企业级框架，都能看到它的身影。掌握策略模式不仅有助于我们更好地理解现有框架的设计思想，还能在实际项目中设计出更加灵活、可扩展的系统。

随着软件开发技术的不断发展，设计模式的应用也在不断演进。策略模式可以与其他设计模式（如工厂模式、状态模式、责任链模式等）结合使用，形成更强大的解决方案。同时，在面对复杂的业务需求和多变的市场环境时，策略模式的核心思想 —— 封装变化、分离关注点 —— 将继续发挥重要作用，帮助我们构建更加健壮和灵活的软件系统。

未来，随着人工智能、大数据等技术的发展，策略模式可能会在更多领域得到应用，例如智能决策系统中不同决策策略的封装和切换，大数据处理中不同数据清洗、分析策略的动态选择等。作为开发者，我们需要不断深入理解设计模式的本质，灵活运用它们来解决实际问题，提升软件设计和开发的能力。