第1篇：从“促销活动”的一堆 if-else 说起
第1篇：从“促销活动”的一堆 if-else 说起
摘要：电商促销的满减、打折、立减逻辑写在同一个方法里，导致代码臃肿、难以扩展。本文从真实痛点出发，揭示策略模式如何通过算法封装消除条件分支，并附上场景判断表。
本文是《Java 23 种设计模式：从踩坑到精通》策略模式长文的扩充短文第1篇，帮助你碎片化掌握核心知识点。
你有没有写过这样的代码？
doublecalculate(Orderorder,StringpromotionType){if("满减".equals(promotionType)){returnorder.getTotal()-(order.getTotal()/200)*50;}elseif("打折".equals(promotionType)){returnorder.getTotal()*0.8;}elseif("立减".equals(promotionType)){returnorder.getTotal()-30;}returnorder.getTotal();}每次新增一种促销方式，就得在这个方法里再加一个else if。代码越来越长，逻辑越来越混乱。更糟糕的是，修改满减逻辑可能会不小心影响到打折逻辑，测试也变得异常困难。
策略模式正是为此而生
它把每一种算法封装成一个独立的策略类，让它们可以相互替换。调用方只需要选择一个策略，交给上下文执行，至于算法内部怎么算，调用方根本不需要关心。
你的场景该不该用策略模式？
| 判断标准 | 是 → 用策略模式 | 否 → 用其他方式 |
|---|---|---|
| 同一个操作有多种实现方式，且可能动态切换 | ✅ | ❌ |
| 算法逻辑复杂，相互独立，需要避免冗长的条件语句 | ✅ | ❌ |
| 未来需要增加新的算法，且不希望修改原有代码 | ✅ | ❌ |
| 只有两三种固定不变的简单分支 | ❌ | 直接使用if-else即可 |
一句话总结：同一操作、多种算法、需要灵活切换 → 用策略模式，告别 if-else 泥潭。
📖完整长文入口：本文是策略模式扩充系列的第1篇。如果你想一次性阅读完整内容（含UML、完整代码、框架应用、面试追问等），请查看原长文：
👉 《Java 23 种设计模式：从踩坑到精通 | 策略模式》
🔗 系列导航：
- 上一篇：无（本篇为首篇）
- 下一篇：第2篇：策略模式三大角色拆解与UML
- 返回扩充系列目录 🔥 订阅本专栏，不错过每一篇
- 原系列总目录 🔥 订阅本专栏，不错过每一篇