策略模式通过映射表或策略类替代switch-case，实现行为可配置、易扩展；支持语义键名、纯函数处理、兜底逻辑；可用map或类封装状态与依赖；每个策略自判断适用性；复杂场景需分层嵌入流程控制。
直接用策略模式替换 switch-case，核心是把“根据值选行为”这件事从硬编码里抽出来，变成可配置、可扩展、不改旧代码就能加新逻辑的结构。
用对象映射替代 case 列表
最轻量、最常用的方式：把每个 case 对应的处理逻辑封装成函数，用一个普通对象做键值映射。调用时直接查表执行，无需判断和跳转。
- 键名用语义清晰的字符串或枚举（如 'save'、'delete'），避免魔法值
- 值是纯函数，只负责本分支逻辑，不耦合其他分支
- 未命中时用逻辑运算符兜底：handlerMap[action]?.() || handlerMap.default?.()
- 新增类型只需往对象里加一项，完全不碰原有逻辑
用 Map 或 Class 封装更复杂的策略
当策略需要状态、依赖注入或运行时动态注册时，对象字面量就不够用了。这时可用 Map 或策略类配合工厂函数。
- Map 支持任意类型 key（包括 Symbol、对象），适合 key 不是简单字符串的场景
- 每个策略封装为独立 class，构造时可注入日志、API 客户端等依赖，便于单元测试
- 工厂函数如 getStrategy(type) 统一返回匹配实例，内部调用各策略的 supports() 方法判断是否适用
- 支持运行时注册：某个模块加载时自动把自己注册进全局策略池，主流程无感知
让识别逻辑也策略化
别在工厂里写 if-else 判断该用哪个策略——这又回到了老问题。真正解耦的关键，是让每个策略自己决定“我能不能处理这个输入”。
- 每个策略实现 supports(input) 方法，支持多种匹配方式：精确值、前缀、正则、范围分类（如 num => num > 100 ? 'large' : 'small'）
- 也可将匹配规则外置为 JSON 配置，比如 {'type': 'payment', 'rules': {'method': '^alipay.*$'}}，运行时加载
- 这样连“怎么判断该用谁”都可插拔，新增一种识别方式也不用改调度层
配合流程控制做分层决策
策略模式不是万能的，它擅长处理“同一件事、多种做法”，但复杂业务常需多层判断。这时要把策略嵌入流程控制中，而不是取代它。
- 外层用 if/else 或 switch 判断大类（如 if (isBatch) { useBatchStrategy() } else { useSingleStrategy() }）
- 内层再交由对应策略族处理细节（如批量策略里再按文件格式选 parser）
- 递归场景下，每个节点类型可绑定专属策略，switch 只留一层类型分发，其余交给策略递归执行
- 避免把所有条件塞进一个巨型策略映射表，按业务维度合理切分层级
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
