策略模式替代switch-case的核心是将条件分支逻辑抽象为可插拔的策略接口，通过统一接口定义行为契约、为每种分支实现解耦的具体策略类，并借助工厂或注册表动态调度，配合可配置的识别逻辑实现开闭原则。
用策略模式替代 switch-case，核心是把“根据条件选行为”这件事，从硬编码分支里抽出来，变成可插拔、可扩展、不改旧代码就能加新逻辑的结构。不是简单换写法，而是重构判断逻辑的组织方式。
定义统一策略接口
先抽象出所有分支共有的行为契约，比如处理订单、计算折扣、解析消息等。接口只声明一个执行方法，不暴露实现细节：
- 接口名要体现业务意图，如 OrderHandler、DiscountStrategy、MessageProcessor
- 方法参数应包含该策略所需全部上下文（如 Order 对象、原始数据、配置项）
- 避免在接口中塞太多无关方法，保持单一职责
为每种分支实现具体策略
每个 case 对应一个独立类，实现上述接口。这类类不依赖其他策略，也不感知自己被谁调用：
- 例如：支付场景下，AlipayHandler、WechatPayHandler、BankTransferHandler 各自封装对应逻辑
- 策略类之间完全解耦，新增一种支付方式，只需新增一个类，无需修改已有任何代码
- 可配合构造器注入依赖（如日志、远程服务），便于单元测试
用工厂或注册表统一调度
去掉 switch 的关键一步，是让调用方不再手动判断类型再 new 实例，而是通过一个中心化入口获取匹配的策略：
立即学习“Java免费学习笔记（深入）”；
- Spring 环境下，可用 @Component + @HandlerType("ALIPAY") 注解标记策略类，启动时自动扫描注册进 Map
- 非 Spring 场景，可用静态注册表（如 ConcurrentHashMap
），由各策略类在 static 块中自行注册 - 工厂方法如 getHandler(String type) 内部遍历策略列表，用 supports(type) 判断是否匹配，返回首个满足条件的实例
配合注解或配置驱动识别逻辑
避免在工厂里写 if-else 或 switch 来匹配类型，让识别逻辑也策略化：
- 每个策略类自带识别能力，比如重写 supports(String input) 方法，支持正则、前缀、枚举值等多种判断方式
- 也可将识别规则外置为配置项（如 application.yml 中定义 type → class 映射），运行时加载
- 这样连“怎么判断该用哪个策略”都可配置、可替换，真正实现开闭原则
