当前位置：首页 > article >正文

Java 与设计模式（14）：策略模式

article 2024/11/29 10:37:57

一、定义

策略模式（Strategy Pattern）是行为型设计模式之一，它定义了一系列算法，并将每一个算法封装起来，使它们可以互换使用，算法的变化不会影响使用算法的用户。策略模式让算法独立于使用它的客户而变化，从而避免使用多重条件判断语句。

策略模式的主要目的是将算法族封装在一起，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

策略模式通常包含以下角色：

策略接口（Strategy Interface）：定义所有支持的算法的公共接口。此接口通常由一组相关类实现，这些类提供了具体的算法实现。
具体策略类（Concrete Strategy）：实现策略接口，提供具体的算法实现。
上下文（Context）：维护一个策略类的引用，负责调用当前策略对象的算法方法。上下文不实现算法，而是依赖于策略对象去实现。
客户端（Client）：创建具体策略对象，并设置给上下文对象，从而影响上下文的行为。

策略模式的实现通常涉及以下步骤：

定义策略接口，声明一系列相关操作的公共方法。
实现具体策略类，每个类对应一种算法的实现。
创建上下文类，持有策略接口的引用，并提供方法来设置和获取当前的策略对象。
客户端代码根据需要创建具体策略对象，并将其设置给上下文，然后通过上下文来执行算法。

二、Java示例

下面这个示例展示了一个简单的支付系统，其中不同的支付策略（如信用卡支付、PayPal支付等）被封装在各自的策略类中。

首先，我们定义一个支付策略接口：

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

然后，我们实现具体的支付策略：

// 信用卡支付策略
public class CreditCardPaymentStrategy implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("Paying " + amount + " using Credit Card.");
    }
}

// PayPal支付策略
public class PayPalPaymentStrategy implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("Paying " + amount + " using PayPal.");
    }
}

接下来，我们创建上下文类，它将使用策略接口：

// 上下文类
public class PaymentContext {
    private PaymentStrategy strategy;

    // 设置支付策略
    public void setPaymentStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    // 执行支付
    public void executePayment(int amount) {
        strategy.pay(amount);
    }
}

最后，客户端代码可以这样使用策略模式：

public class Client {
    public static void main(String[] args) {
        PaymentContext context = new PaymentContext();

        // 使用信用卡支付
        context.setPaymentStrategy(new CreditCardPaymentStrategy());
        context.executePayment(1000);

        // 更改策略为PayPal支付
        context.setPaymentStrategy(new PayPalPaymentStrategy());
        context.executePayment(500);
    }
}

在这个示例中，PaymentContext 类是上下文，它维护一个对 PaymentStrategy 接口的引用。CreditCardPaymentStrategy 和 PayPalPaymentStrategy 是具体的策略实现。客户端代码通过改变上下文的策略来改变支付方式，而不需要修改上下文或其他策略的代码。这样，支付方式的变化不会影响使用支付系统的其他部分，符合开闭原则。

三、优点

算法的封装性：策略模式将算法封装在独立的策略类中，使得算法的变化不会影响到使用算法的客户端代码。
代码的可维护性：当需要新增算法时，只需新增一个策略类实现策略接口，无需修改原有代码，符合开闭原则。
算法的可替换性：客户端可以通过改变策略对象的选择来改变算法，使得算法可以灵活替换。
提高算法的复用性：策略模式使得算法可以在不同的上下文中被重用，而不需要针对每个上下文单独编写算法。
减少条件判断：策略模式避免了在客户端代码中使用多重条件判断来选择算法，使得代码更加清晰。

四、缺点

客户端需要了解策略类：客户端需要了解不同策略类之间的区别，以便能够正确地使用它们。
类的膨胀：如果策略模式使用不当，可能会导致系统中存在大量的策略类，使得系统变得复杂。
所有策略类都需要实现接口：如果策略接口发生变化，所有实现该接口的策略类都需要进行相应的修改。
可能存在性能问题：每次使用策略时都需要实例化一个策略对象，这可能会导致不必要的性能开销。
策略类之间的共享数据问题：如果策略类之间需要共享数据，那么需要通过外部传入或者使用全局变量等方式来实现，这可能会使得代码的维护性降低。

五、使用场景

策略模式的常见使用场景包括：

多种算法的选择：当一个系统需要在运行时从多种算法中选择一种时，策略模式可以使得算法的变化独立于客户端。
算法族的封装：当存在一组相关的算法，并且这些算法可以相互替换时，策略模式可以将每个算法封装在单独的类中。
需要动态选择算法：如果算法的选择依赖于客户端输入或者某个运行时参数，策略模式可以在运行时动态地更改算法。
复杂的条件判断：在需要通过多重条件判断来选择执行不同逻辑的情况下，策略模式可以简化这些条件判断，使得代码更加清晰。
支付系统：如前述示例，不同的支付方式（信用卡、PayPal、微信支付等）可以作为不同的策略。
排序算法：在一个需要多种排序算法（如快速排序、归并排序、堆排序等）的系统中，每种排序算法可以作为一个策略。
图形渲染：在图形界面程序中，不同的图形对象可能需要不同的渲染策略。
数据库操作：在访问不同类型数据库（如MySQL、Oracle、MongoDB等）时，可以为每种数据库实现一个策略。
缓存策略：在缓存系统中，可以有多种缓存淘汰策略（如LRU、FIFO等），每种策略可以作为一个独立的策略类。
游戏AI：在游戏开发中，不同的角色可能有不同的AI行为（如追逐、逃避、攻击等），每种行为可以是一个策略。
用户界面：不同的用户界面元素可能需要不同的布局策略，如网格布局、流布局等。
折扣策略：在电子商务网站中，可以有多种折扣策略（如满减、打折、买一赠一等），每种策略可以作为一个独立的类。
文件格式转换：在需要支持多种文件格式转换的系统中，每种文件格式的转换可以作为一个策略。
数据加密：在需要多种加密算法（如AES、DES、RSA等）的系统中，每种加密算法可以作为一个策略。
策略游戏：在策略游戏中，不同的战术或策略可以作为不同的策略类。

六、注意事项

以下是一些需要避免的情况：

过度使用：策略模式并不是解决所有问题的万能钥匙。如果只有一种算法或者算法的选择不经常变化，使用策略模式可能会导致不必要的复杂性。
策略类与上下文类耦合：策略模式的目的是将算法的实现与使用算法的代码解耦。如果策略类与上下文类（Context）耦合得太紧密，就会失去策略模式的优势。
策略接口设计不当：策略接口应该定义清晰且一致的方法，以便不同的策略可以互换。如果接口设计得过于复杂或不一致，可能会导致策略难以实现或替换。
策略类太多：如果为每种可能的情况都创建一个策略类，可能会导致类的数量过多，增加维护成本。应该考虑是否有一些策略可以合并或者是否有一些策略可以通过参数配置来实现。
策略选择逻辑复杂：策略的选择逻辑应该简单明了。如果策略选择逻辑过于复杂，可能会使得代码难以理解和维护。
忽视策略的初始化：策略对象可能需要一些初始化数据才能正确工作。如果忽视了这一点，可能会导致策略对象在运行时出现错误。
忽视策略的销毁：如果策略对象持有资源（如数据库连接、文件句柄等），则需要确保这些资源在策略对象不再使用时被正确释放。
策略类的性能问题：策略类的性能可能会影响整个系统的性能。在设计策略时，应该考虑策略的性能，并在必要时进行优化。
策略类的状态管理：如果策略类持有状态，需要确保状态在策略切换时被正确处理。否则，可能会导致不一致的状态或错误。
策略类的错误处理：策略类应该能够处理错误，并在出现错误时提供清晰的反馈。如果忽视了错误处理，可能会导致系统在运行时出现不可预测的行为。
过度设计：不要为了使用策略模式而使用策略模式。在某些情况下，简单的条件判断可能比引入策略模式更加合适。
依赖过多：确保策略之间的依赖关系最小化，以保持每个策略的独立性和可互换性。

七、在spring 中的应用

在Spring源码中，策略模式被应用在多个地方，以下是一些具体的使用场景：

版本资源解析：
在Spring MVC中，处理静态资源时，使用了策略模式来定义不同的版本资源解析策略。例如，VersionPathStrategy 接口定义了如何从请求路径中提取和嵌入资源版本的方法。具体的策略实现类，如 FixedVersionStrategy 和 ContentVersionStrategy，封装了不同的版本解析逻辑。
Bean定义解析：
Spring在解析Bean定义时，使用了策略模式。BeanDefinitionParser 接口定义了解析Bean定义的策略，不同的解析器实现类负责解析不同类型的Bean定义。
类型过滤：
在Spring的组件扫描和配置中，TypeFilter 接口用于决定哪些类型的Bean定义应该被包含或排除。实现这个接口的不同类提供了不同的过滤策略。
导入选择器和注册器：
在Spring的配置类处理中，ImportSelector 和 ImportBeanDefinitionRegistrar 接口使用了策略模式。这些接口允许Spring根据不同的策略动态地导入配置类或注册Bean定义。
环境抽象：
Spring的 Environment 抽象使用了策略模式，通过不同的 PropertySource 实现类来提供不同来源的属性值。
资源加载：
ResourceLoader 接口及其实现类使用了策略模式，以便根据不同的资源类型（如文件系统资源、类路径资源等）加载资源。
事务管理：
Spring的事务管理器使用了策略模式，通过不同的事务管理器实现类来提供不同的事务管理策略，如编程式事务和声明式事务。
解析策略工具类：
ParserStrategyUtils 类是一个解析策略工具类，它使用策略模式来处理不同类型的解析任务，如Bean定义解析、环境解析等。