冠军资讯
半杯凉茶在实际的软件开发过程中，我们经常会遇到需要根据不同条件执行不同逻辑的情况。如果仅仅依靠大量的 if...else 或 switch...case 语句，会导致代码臃肿、难以维护，也就是我们常说的“万能类”。今天我们就来聊聊如何利用策略模式 (Strategy Pattern) 配合方法器来优雅地解决这类问题，提升代码的可扩展性和可读性。
问题场景：多种支付方式的集成
假设我们需要开发一个电商系统，支持多种支付方式：支付宝、微信支付、银行卡支付。如果使用传统的 if...else 结构，代码可能会变成这样：
public class OrderService {
public void pay(String paymentMethod, double amount) {
if ("alipay".equals(paymentMethod)) {
// 支付宝支付逻辑
System.out.println("使用支付宝支付" + amount + "元");
} else if ("wechat".equals(paymentMethod)) {
// 微信支付逻辑
System.out.println("使用微信支付" + amount + "元");
} else if ("bankcard".equals(paymentMethod)) {
// 银行卡支付逻辑
System.out.println("使用银行卡支付" + amount + "元");
} else {
System.out.println("不支持的支付方式");
}
}
}
这种写法的缺点显而易见：每增加一种新的支付方式，都需要修改 OrderService 类的代码，违反了开闭原则。同时，大量的条件判断使得代码难以阅读和维护。这就像我们在 Nginx 配置中，如果所有规则都写在一个 server 块里，当业务逻辑复杂时，配置文件会变得非常庞大且难以管理，不利于进行反向代理和负载均衡的配置。
策略模式的核心思想
策略模式的核心思想是将算法封装到独立的策略类中，然后通过一个上下文类来选择使用哪个策略。这样，我们可以动态地切换算法，而无需修改上下文类的代码。
简单来说，就是定义一系列的算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而独立变化。
使用方法器简化策略模式
在 Java 中，我们可以使用接口来实现策略模式。首先，定义一个支付接口：
public interface PaymentStrategy {
void pay(double amount);
}
然后，创建不同的支付策略类，实现该接口：
public class AlipayPayment implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println("使用支付宝支付" + amount + "元");
}
}
public class WechatPayment implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println("使用微信支付" + amount + "元");
}
}
public class BankCardPayment implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println("使用银行卡支付" + amount + "元");
}
}
接下来，我们需要一个上下文类来选择使用哪个策略。这里，我们可以使用方法器（Method Invoker）来简化上下文类的实现。方法器本质上就是一个可以动态调用方法的工具类，它可以根据不同的参数来调用不同的策略类的方法。
import java.util.HashMap;
import java.util.Map;
public class PaymentContext {
private Map<String, PaymentStrategy> paymentStrategies = new HashMap<>();
public PaymentContext() {
paymentStrategies.put("alipay", new AlipayPayment());
paymentStrategies.put("wechat", new WechatPayment());
paymentStrategies.put("bankcard", new BankCardPayment());
}
public void pay(String paymentMethod, double amount) {
PaymentStrategy paymentStrategy = paymentStrategies.get(paymentMethod);
if (paymentStrategy != null) {
paymentStrategy.pay(amount);
} else {
System.out.println("不支持的支付方式");
}
}
}
在这个例子中，PaymentContext 就是上下文类，它维护了一个策略类的 Map。当需要支付时，只需要根据支付方式从 Map 中获取对应的策略类，然后调用其 pay 方法即可。如果需要新增一种支付方式，只需要实现 PaymentStrategy 接口，然后将其添加到 paymentStrategies Map 中，无需修改 PaymentContext 类的代码。
实战避坑经验
- 策略类的选择：选择策略类的时候要考虑性能问题。如果策略类的逻辑比较复杂，可以考虑使用缓存来提高性能。例如，对于高并发的场景，可以利用 Redis 缓存支付渠道的配置信息，减少数据库的访问压力。
- 策略类的初始化：策略类的初始化方式也很重要。如果策略类的初始化比较耗时，可以考虑使用懒加载的方式，或者使用 Spring 的 Bean 管理机制来管理策略类。
- 异常处理：在策略类的
pay方法中，要做好异常处理。例如，可以捕获支付接口的异常，然后进行重试或者回滚操作。 - 参数校验：在调用策略类的
pay方法之前，要对参数进行校验，防止出现空指针异常或者非法参数异常。可以使用类似 ValidationUtils 的工具类进行参数校验。 - 结合工厂模式：在更复杂的场景下，可以将策略模式与工厂模式结合使用，通过工厂模式来创建策略类的实例，进一步降低代码的耦合度。比如在 Spring Boot 项目中，可以利用 BeanFactory 来管理策略类，实现策略的动态注入。
总结
通过使用策略模式和方法器，我们可以有效地解决代码臃肿、难以维护的问题。策略模式可以将算法封装到独立的策略类中，而方法器可以简化上下文类的实现。这种方式可以提高代码的可扩展性和可读性，使得代码更加灵活和易于维护。在实际开发中，我们应该根据具体的场景选择合适的策略模式实现方式，并注意一些避坑经验，才能更好地发挥策略模式的优势。
