巧用策略模式：应对复杂业务逻辑中的多变需求

在后端开发中，我们经常会遇到这样的场景：对于同一个功能，存在多种不同的实现方式，并且这些实现方式会随着业务的变化而变化。例如，电商平台针对不同的用户群体、不同的促销活动，采用不同的优惠计算策略。如果直接在代码中堆砌大量的 if-else 或 switch-case 语句，不仅代码可读性差，而且难以维护和扩展。这时候，Strategy 策略模式就能派上大用场，它允许我们根据不同的情况选择不同的策略，从而实现灵活的业务逻辑。

策略模式的核心思想

策略模式的核心思想是将算法与使用算法的客户端分离。它定义了一系列算法，并将每一个算法封装到独立的类中，使得它们可以互相替换。客户端只需要选择合适的策略，而无需关心算法的具体实现。

策略模式主要包含以下几个角色：

• Strategy（策略接口）： 定义所有支持的算法的公共接口。
• ConcreteStrategy（具体策略）： 实现了 Strategy 接口的具体算法。
• Context（上下文）： 持有一个 Strategy 对象的引用，负责在运行时选择合适的策略。

策略模式的底层原理

策略模式的实现依赖于面向对象编程中的接口和多态特性。通过定义一个策略接口，我们可以将不同的算法实现类都视为该接口的实例。在运行时，Context 对象可以根据需要选择不同的策略实例，从而实现不同的行为。

这种设计模式的核心优势在于其灵活性和可扩展性。当需要新增一种算法时，只需要实现新的 ConcreteStrategy 类即可，无需修改 Context 类的代码。这符合开闭原则，降低了代码的维护成本。

优惠券计算策略的实战演练

假设我们正在开发一个电商平台，需要实现优惠券的计算功能。平台支持多种类型的优惠券，例如：

• 满减券：订单满一定金额，减免一定金额。
• 折扣券：订单享受一定比例的折扣。
• 直减券：直接减免一定金额。

我们可以使用策略模式来实现这个功能。首先，定义一个 Strategy 接口：

// 策略接口
interface DiscountStrategy {
    double calculateDiscount(double price);
}

然后，实现具体的策略类：

// 满减券策略
class FullReductionStrategy implements DiscountStrategy {
    private double threshold; // 满减门槛
    private double reduction; // 减免金额

    public FullReductionStrategy(double threshold, double reduction) {
        this.threshold = threshold;
        this.reduction = reduction;
    }

    @Override
    public double calculateDiscount(double price) {
        if (price >= threshold) {
            return reduction;
        } else {
            return 0;
        }
    }
}

// 折扣券策略
class DiscountRateStrategy implements DiscountStrategy {
    private double rate; // 折扣率

    public DiscountRateStrategy(double rate) {
        this.rate = rate;
    }

    @Override
    public double calculateDiscount(double price) {
        return price * (1 - rate); // 折扣后的价格，这里返回的是折扣后的价格，而不是减免的金额
    }
}

// 直减券策略
class DirectReductionStrategy implements DiscountStrategy {
    private double reduction; // 减免金额

    public DirectReductionStrategy(double reduction) {
        this.reduction = reduction;
    }

    @Override
    public double calculateDiscount(double price) {
        return reduction; // 直接返回减免金额
    }
}

最后，定义 Context 类：

// 上下文类
class ShoppingCart {
    private DiscountStrategy discountStrategy; // 持有策略对象的引用

    public void setDiscountStrategy(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    public double checkout(double price) {
        // 根据选择的策略计算折扣
        double discountAmount = discountStrategy.calculateDiscount(price);
        return price - discountAmount;
    }
}

使用示例：

public class Main {
    public static void main(String[] args) {
        ShoppingCart cart = new ShoppingCart();
        double price = 100;

        // 使用满减券
        cart.setDiscountStrategy(new FullReductionStrategy(80, 20));
        System.out.println("满减后价格：" + cart.checkout(price));

        // 使用折扣券
        cart.setDiscountStrategy(new DiscountRateStrategy(0.8));
        System.out.println("折扣后价格：" + cart.checkout(price));

        // 使用直减券
        cart.setDiscountStrategy(new DirectReductionStrategy(10));
        System.out.println("直减后价格：" + cart.checkout(price));
    }
}

实战避坑经验

• 策略的选择时机： 策略的选择可以在编译时确定，也可以在运行时动态确定。如果在编译时就能确定策略，可以直接在代码中指定；如果在运行时才能确定策略，可以通过配置文件、数据库等方式来动态选择。
• 策略的维护： 当策略的数量较多时，可以考虑使用工厂模式或依赖注入来管理策略。这样可以降低代码的耦合度，提高代码的可维护性。
• 避免过度设计： 并非所有的 if-else 语句都需要使用策略模式来解决。只有当算法的变化较为频繁，且需要灵活切换时，才适合使用策略模式。过度使用策略模式会增加代码的复杂性。
• 结合配置中心动态调整策略： 对于一些复杂的业务场景，例如风控策略，常常需要根据实时数据进行动态调整。可以结合配置中心（如 Apollo、Nacos）来实现策略的动态更新，而无需重启服务。例如，根据用户的风险等级，动态切换不同的风控策略，有效降低误判率和提升风控效率。

在实际项目中，我们还会遇到一些其他的挑战，例如高并发场景下的策略切换、策略的缓存等。这时候，可以结合其他的技术手段，例如线程池、缓存中间件（如 Redis）等，来优化策略模式的性能。

总结

策略模式是一种非常有用的设计模式，它可以帮助我们应对复杂业务逻辑中的多变需求。通过将算法与使用算法的客户端分离，策略模式提高了代码的灵活性、可扩展性和可维护性。在实际项目中，我们可以根据具体的场景选择合适的策略模式实现方式，从而更好地应对业务的变化。