多层嵌套if-else应重构为多态或策略模式，核心是将判断逻辑从主流程剥离，由类型或状态决定行为；需满足分支依据稳定可枚举、各分支行为差异明显、有单元测试兜底；定义精简行为接口，为每种分支建单一职责实现类，用策略容器统一管理并设默认策略。
直接把多层嵌套 if-else 拆成多态或策略模式，核心不是“换写法”，而是把“判断逻辑”从主流程里剥离出去，让类型或状态决定行为，而不是靠一堆 if 去猜它该干什么。
先确认这个 if-else 真的适合重构
不是所有嵌套都值得上多态。重点看三点：
- 分支依据是否稳定、可枚举——比如 order.getType()、user.getRole()、payment.getMethod() 这类字段，值是有限的几个枚举或字符串
- 每个分支干的事是否差异明显——比如“VIP 用户打 8 折”“企业用户走合同价”“游客只能查不能买”，行为逻辑不重叠、不易复用
- 有没有测试兜底——没覆盖单元测试的代码，别急着动；可用 Copilot 快速生成基础用例，再跑一遍确保行为没变
定义一个干净的行为接口
别贪大求全，只封装那个被反复判断的“动作”。例如处理订单，就只提 process()；算折扣，就只提 calculate(Order order)：
- 接口名要直白，比如 OrderHandler、DiscountStrategy、NotificationSender
- 方法参数尽量精简，只传真正需要的数据；外部闭包变量（如税率、配置开关）得显式传入，否则迁移后容易空指针
- 避免在接口里塞无关方法，比如一个发短信策略接口，别顺手加个日志打印方法
为每种分支建一个实现类
原来 if (type == "wechat") { ... } 的整块逻辑，现在搬进 WeChatNotificationSender 类的 send() 方法里；if (type == "email") 就对应 EmailNotificationSender。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 类名要能一眼看出职责，不靠注释也能懂
- 每个类只专注一件事，不掺杂其他分支的判断或兜底逻辑
- 如果多个分支有共用逻辑（比如都要校验手机号），抽成工具方法或基类，但别为了“复用”强行抽象出深继承链
用策略容器替代硬编码分支
原来散落在各处的 if 判断，现在统一收口到一个地方——比如 Spring 中用 @Qualifier 注入，或自己维护一个 Map<String, NotificationSender>：
- 注册方式要简单明确：启动时扫描、配置文件加载、或手动 put，别藏在冷门初始化方法里
- 必须设默认策略（DEFAULT）：遇到未知 type 时不崩溃，而是打 warn 日志并返回合理默认值
- 业务代码里不再出现 new 或 if，只写 senderMap.get(order.getChannel()).send(order) 这类一行委托调用
改完之后，加一种新渠道，只需新增一个类 + 注册进 map，不用碰任何原有 if 块。不是更“高级”，而是更贴近业务变化的真实节奏。
