告别“臃肿”条件判断：策略模式实战指南
引言：被if-else支配的恐惧
你是否曾在业务代码中见过长达数十行的if-else嵌套？当产品经理新增需求时，是否只能在这些分支中继续堆砌逻辑？这种"流水账式"编码不仅降低可读性，更会成为后期维护的噩梦。本文将用策略模式(Strategy Pattern)重构复杂条件判断，让你的代码重获优雅。
痛点场景：电商促销系统演化史
假设我们正在开发促销系统，最初需求很简单：
public BigDecimal calculateDiscount(String userType) {
if ("REGULAR".equals(userType)) {
return amount.multiply(0.9); //普通用户9折
} else if ("VIP".equals(userType)) {
return amount.multiply(0.8); //VIP用户8折
} //更多if-else...
}随着业务扩展，增加了新用户首单折扣、节日满减活动等规则，方法膨胀到300行+，每次修改都战战兢兢——这正是策略模式的用武之地。
策略模式重构三部曲
1. 定义策略接口
public interface DiscountStrategy {
BigDecimal calculate(BigDecimal amount);
}2. 实现具体策略类
- 常规策略：
class RegularStrategy implements DiscountStrategy {...} - VIP策略：
class VipStrategy implements DiscountStrategy {...} - 新人策略：
class NewUserStrategy implements DiscountStrategy {...}
3. 创建策略上下文
public class DiscountContext {
private DiscountStrategy strategy;
public void setStrategy(DiscountStrategy strategy) {
this.strategy = strategy;
}
public BigDecimal execute(BigDecimal amount) {
return strategy.calculate(amount);
}
}最新实践：Spring Boot整合策略模式
结合当下主流框架，我们可以更优雅地管理策略：
@Service
public class DiscountService {
@Autowired
private Map<String, DiscountStrategy> strategies; //自动注入所有实现
public BigDecimal applyDiscount(String strategyKey, BigDecimal amount) {
DiscountStrategy strategy = strategies.get(strategyKey);
if (strategy == null) throw new IllegalArgumentException("无效策略");
return strategy.calculate(amount);
}
}优势亮点：
- 新增策略只需添加实现类，无需修改核心逻辑
- 利用Spring的依赖注入自动管理策略对象
- 单元测试可针对单个策略独立测试
适用场景与性能考量
策略模式特别适合以下场景：
- 存在大量条件分支的业务逻辑
- 需要动态切换算法实现
- 存在可能扩展的同类行为
性能提示： 在超高并发场景下，可使用枚举+函数式接口避免对象创建开销：
enum DiscountEnum {
VIP(amount -> amount.multiply(0.8)),
NEW_USER(amount -> amount.multiply(0.7));
private final Function<BigDecimal, BigDecimal> calculator;
// 构造器及调用逻辑省略
}结语：让设计模式服务于工程实践
策略模式不是银弹，但针对条件分支膨胀这类高频痛点，它能显著提升代码的扩展性与可维护性。下次当if-else超过3层时，不妨思考：这段逻辑是否在描述同一类问题的不同解决方案？如果是，策略模式或许就是你代码重构的起点。
真正的架构智慧不在于套用模式，而在于识别那些正在"散发坏味道"的代码片段，并用合适的设计持续重构——这才是资深工程师的核心竞争力。
评论