架构设计之策略模式：告别 if-else 地狱，提升代码可维护性

在日常开发中，我们经常会遇到需要根据不同条件执行不同逻辑的场景。如果处理不当，很容易陷入 if-else 或 switch-case 的泥潭，导致代码臃肿、难以维护。今天，我们就来聊聊如何使用设计模式中的策略模式来优雅地解决这个问题，并结合实际案例，让你彻底摆脱 if-else 地狱。

问题场景重现：多渠道支付系统

假设我们需要开发一个支付系统，支持多种支付渠道，如支付宝、微信支付、银行卡支付等。最初的代码可能会是这样的：

public class PaymentService {

    public void pay(String channel, double amount) {
        if ("alipay".equals(channel)) {
            // 支付宝支付逻辑
            System.out.println("使用支付宝支付了 " + amount + " 元");
        } else if ("wechat".equals(channel)) {
            // 微信支付逻辑
            System.out.println("使用微信支付支付了 " + amount + " 元");
        } else if ("bankcard".equals(channel)) {
            // 银行卡支付逻辑
            System.out.println("使用银行卡支付支付了 " + amount + " 元");
        } else {
            System.out.println("不支持的支付渠道");
        }
    }
}

这样的代码存在明显的问题：

• 可扩展性差：每增加一种支付渠道，都需要修改 pay 方法，违反了开闭原则。
• 可维护性差：if-else 嵌套过多，代码逻辑复杂，难以理解和维护。
• 代码重复：不同支付渠道的支付逻辑可能存在相似之处，但都被分散在 if-else 分支中，造成代码重复。

底层原理深度剖析：策略模式的核心

策略模式的核心思想是将算法封装到独立的策略类中，使它们可以相互替换。客户端通过选择不同的策略来执行不同的算法，而无需关心算法的具体实现。策略模式主要包含以下几个角色：

• 策略接口（Strategy）：定义所有策略类需要实现的接口，通常包含一个执行算法的方法。
• 具体策略类（ConcreteStrategy）：实现策略接口，封装具体的算法。
• 环境类（Context）：持有策略接口的引用，负责在运行时选择具体的策略。

这种设计模式与 Nginx 的模块化设计理念有异曲同工之妙。Nginx 通过不同的模块（例如 ngx_http_proxy_module、ngx_http_ssl_module）来实现不同的功能，客户端可以根据需求选择加载不同的模块，从而实现灵活的功能扩展。这种模块化设计避免了代码的臃肿，提高了系统的可维护性，也方便进行负载均衡和反向代理的配置。

代码/配置解决方案：策略模式重构支付系统

下面，我们使用策略模式来重构支付系统：

1. 定义策略接口：

public interface PaymentStrategy {
    void pay(double amount); // 支付方法
}

2. 实现具体策略类：

public class AlipayStrategy implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("使用支付宝支付了 " + amount + " 元");
    }
}

public class WechatPayStrategy implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("使用微信支付支付了 " + amount + " 元");
    }
}

public class BankcardStrategy implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("使用银行卡支付支付了 " + amount + " 元");
    }
}

3. 创建环境类：

public class PaymentContext {
    private PaymentStrategy paymentStrategy;

    public PaymentContext(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }

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

4. 客户端调用：

public class Client {
    public static void main(String[] args) {
        PaymentContext alipayContext = new PaymentContext(new AlipayStrategy());
        alipayContext.pay(100.0);

        PaymentContext wechatContext = new PaymentContext(new WechatPayStrategy());
        wechatContext.pay(200.0);
    }
}

通过策略模式重构后的代码，每个支付渠道都被封装成一个独立的策略类，新增支付渠道时，只需要添加一个新的策略类即可，无需修改原来的代码，符合开闭原则。代码结构更加清晰，易于维护和扩展。 如果需要使用 Spring 框架，可以将这些 Strategy 类声明为 Bean，然后通过依赖注入的方式在 Context 中使用，这样可以进一步解耦，提高代码的灵活性。例如在配置 Nginx 反向代理时，使用宝塔面板可以图形化配置，但手动修改配置文件可以获得更高的灵活性。

实战避坑经验总结

• 策略类的粒度要适中：如果策略类过于简单，可能会导致策略类的数量过多，增加代码的复杂性。如果策略类过于复杂，可能会导致策略类的复用性降低。
• 策略的选择要合理：策略的选择应该根据实际情况进行，避免过度设计。可以使用工厂模式来创建策略对象，根据不同的参数选择不同的策略。
• 注意并发问题：如果多个线程同时访问同一个策略对象，可能会导致并发问题。可以使用线程安全的策略类，或者使用线程局部变量来保存策略对象。

总之，策略模式是一种非常有用的设计模式，可以帮助我们编写更加灵活、可维护的代码。希望本文能帮助你更好地理解和应用策略模式，告别 if-else 地狱。