java策略模式实战 把ifelse拆成接口实现

一段会员折扣逻辑，if加else if写了七八层，每加一种会员就得动一次老代码，改一次怕一次。这种场景正好是java策略模式的用武之地：把每种算法拆成独立实现，用一个统一接口对外，调用方不再关心具体用哪种。

三个角色的最小实现

public interface Discount {  BigDecimal calc(BigDecimal origin);  }

public class VipDiscount implements Discount {  public BigDecimal calc(BigDecimal origin) {  return origin.multiply(BigDecimal.valueOf(0.8));  }  }

public class NormalDiscount implements Discount {  public BigDecimal calc(BigDecimal origin) {  return origin;  }  }

接口定规矩，实现类各干各的。新增一种会员就是新增一个实现类，老代码一行不动，这就是策略模式换来的东西。

用Map注入收口消灭ifelse

配合Spring更省事：给每个实现类标上Component，注入时用Map收口：

@Autowired  private Map<String, Discount> discountMap;

key是bean的名字，请求里传什么类型就取哪个key，原来那串ifelse缩成一行get。Map里的key建议用常量或者枚举管理，散落各处的魔法字符串是后期维护的坑。不用Spring的话，自己拿枚举或者静态Map把类型和实现登记起来，效果相同。

什么情况别硬上

只有两三个分支、好几年不会加新类型的，ifelse反而直白，硬拆成接口是过度设计，读代码的人得多跳好几层。判断标准看变化频率：类型持续增加、每种逻辑还会膨胀的，才值得上策略模式。

它的价值不在炫技，在把变化的部分隔离出去：新增不动存量，改折扣只碰一个类，测试范围也跟着变小。