核心是将状态判断交给策略对象自主完成，通过canhandle和execute双方法封装判断与执行逻辑，配合工厂动态选取策略，使业务代码彻底消除if/else。

核心是把“状态判断”从调用方剥离，交给策略对象自己决定是否响应，再由统一接口执行动作——多态负责行为分发，策略模式负责动态路由，两者结合后，业务主流程里不再出现任何 if、else 或 switch。

定义无判断逻辑的策略接口

接口只声明“能做什么”，不暴露“为什么做”或“依据什么做”。比如处理订单异常：

• 不要写 handle(String errorCode) —— 这会逼你在外面先解析 errorCode 再传入，判断逻辑仍在外部
• 要写 canHandle(TradeContext context) 和 execute(TradeContext context) —— 判断和执行都封装在策略内部
• 所有策略共用同一个上下文对象（如 TradeContext），包含订单号、错误码、金额、时间等字段，策略按需读取

让每个策略自主决定是否匹配

不同状态对应不同策略类，每个类只专注一种场景：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• NoProcessorFoundStrategy：检查 context.getErrorCode().equals("NO_PROCESSOR")
• ValidationFailedStrategy：检查 context.hasValidationError()
• TimeoutStrategy：检查 context.getElapsedMs() > 30000
• 新增状态？加一个新类，实现 canHandle 和 execute，不改任何已有代码

用工厂统一管理策略选取

避免手动维护 Map 时又写一遍 if-else：

• Spring 环境下，所有策略类标注 @Service 并实现标记接口（如 OrderFailureStrategy）
• 工厂类启动时调用 applicationContext.getBeansOfType(OrderFailureStrategy.class) 拿到全部实例
• 执行时遍历所有策略，调用 canHandle(context)，找到第一个返回 true 的即刻执行 execute(context)
• 可加缓存优化：首次匹配成功后，将 context 的关键特征（如错误码）与策略映射起来，后续直接查表

业务代码只剩一行调用

原来散落在各处的状态判断被彻底收口：

• 老写法：if ("TIMEOUT".equals(code)) { handleTimeout(); } else if ("VALIDATION_FAIL".equals(code)) { handleValidation(); }
• 新写法：failureStrategyFactory.selectAndExecute(context);
• 上下文对象承载全部必要信息，策略之间不共享状态，也不互相调用
• 测试时可单独注入某个策略，验证其 canHandle 和 execute 行为，无需绕过分支逻辑

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南