策略模式在Java中如何避免过多的if-else判断？

Question

在Java开发中，面对多个条件分支的业务逻辑，常常会使用大量的if-else语句进行判断，但这种方式会导致代码冗长、难以维护。策略模式是一种常用的行为型设计模式，它通过将算法或行为封装成独立的类，使它们可以互换使用，从而有效替代冗余的if-else逻辑。 那么，如何在Java中通过策略模式优雅地消除冗余的if-else判断？请结合实际业务场景，谈谈你对策略模式的理解、实现方式以及其在扩展性和可维护性方面的优势。

Answer 1

策略模式：优雅消除Java中冗余if-else逻辑的利器

1. 从if-else说起：条件分支的痛点

在Java开发中，面对多个条件分支的业务逻辑时，开发者常常使用大量的if-else语句进行判断。例如，一个订单系统中根据不同的订单类型（普通订单、团购订单、预售订单等）执行不同的处理逻辑：

if ("normal".equals(orderType)) {
    // 处理普通订单
} else if ("group".equals(orderType)) {
    // 处理团购订单
} else if ("pre".equals(orderType)) {
    // 处理预售订单
} else {
    throw new IllegalArgumentException("未知订单类型");
}

虽然这种写法简单直接，但随着业务逻辑的复杂化，代码变得冗长、难以维护，且违反了开闭原则（对扩展开放，对修改关闭）。

2. 策略模式的引入：行为封装与解耦

策略模式是一种常用的行为型设计模式，它通过将算法或行为封装成独立的类，使它们可以互换使用。

核心思想是将每个条件分支封装为一个独立的策略类，统一实现一个策略接口，从而实现逻辑解耦。

结构图如下：

graph TD A[Context] --> B(Strategy) B --> C[ConcreteStrategyA] B --> D[ConcreteStrategyB] B --> E[ConcreteStrategyC]

• Strategy接口：定义策略行为的公共方法。
• ConcreteStrategy类：实现具体的策略逻辑。
• Context类：持有策略接口的引用，调用策略对象执行逻辑。

3. 实际业务场景示例：支付方式处理

假设我们有一个电商平台，需要根据不同的支付方式（支付宝、微信、银联）执行不同的支付逻辑。

支付方式	策略类
支付宝	AlipayPaymentStrategy
微信	WechatPaymentStrategy
银联	UnionPayPaymentStrategy

定义统一的策略接口：

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

具体策略类实现如下：

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

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

上下文类：

public class PaymentContext {
    private PaymentStrategy strategy;

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

    public void executePayment(double amount) {
        strategy.pay(amount);
    }
}

客户端调用示例：

PaymentContext context = new PaymentContext();
context.setStrategy(new AlipayPaymentStrategy());
context.executePayment(100.0);

4. 扩展性与可维护性分析

采用策略模式后，代码具备良好的扩展性和可维护性：

• 新增策略无需修改已有代码：符合开闭原则，新增一个支付方式只需添加新的策略类，无需改动上下文。
• 策略可复用：多个上下文可共享相同的策略实现。
• 便于单元测试：每个策略类独立，可单独进行测试。
• 配置化策略：可通过Spring等框架实现策略的自动注入，进一步提升灵活性。

例如，通过Spring的@Qualifier机制注入策略：

@Autowired
@Qualifier("alipayPaymentStrategy")
private PaymentStrategy paymentStrategy;