多层嵌套if-else应重构为多态或策略模式,核心是将判断逻辑从主流程剥离,由类型或状态决定行为;需满足分支依据稳定可枚举、各分支行为差异明显、有单元测试兜底;定义精简行为接口,为每种分支建单一职责实现类,用策略容器统一管理并设默认策略。

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










