长函数拆分的核心是单一职责、命名清晰、调用直观；优先处理多职责、深嵌套、重复逻辑、依赖注释的代码段；常用提取方法、卫语句、策略模式等手法，确保可读性与可维护性。
把长函数拆分清晰，核心是让每段代码只做一件事、名字能说清它在干什么、调用关系一眼可读。不追求一次全拆完，从最干扰阅读的那块开始。
识别该拆的“关键段”
不是所有长函数都要大改，优先处理这几类：
- 一段逻辑做了不止一个事（比如既查库存又发通知还记日志）
- 出现三层以上 if / for 嵌套，或连续多个 if-else 分支
- 有重复计算、重复判断，或相同结构在不同位置反复出现
- 某段代码加了注释才看得懂，比如“// 校验用户是否有权限且未过期且非试用期”
用提取方法（Extract Method）切出职责
这是最常用也最安全的手法。重点不是“怎么剪”，而是“剪完叫什么”：
- 方法名用动宾短语，比如 validateOrderItems()、sendPaymentConfirmationEmail()，而不是 doCheck() 或 processPart1()
- 剪出来的代码必须有明确输入输出，避免依赖大量外部字段；如果需要太多参数，说明它和原类耦合太紧，考虑下一步“封装成对象”
- 剪完立刻运行测试——哪怕只是验证返回值是否一致，别跳过这步
用卫语句（Guard Clause）替代深层嵌套
与其写 if (x) { if (y) { if (z) { ... } } }，不如提前拦截异常路径：
- 把 null 判断、状态校验、前置条件检查放在开头，直接 return 或 throw
- 例如：把 if (order == null) throw new IllegalArgumentException(); 放第一行，后面代码就默认 order 非空，不用再包一层 if
- 复杂条件可先抽成布尔变量：boolean isEligibleForDiscount = user.isPremium() && order.getTotal() > 1000;，再用它写 if
合并相似流程，用策略或模板收口
当发现多个地方都在写几乎一样的流程（比如“查数据→转DTO→发MQ→记日志”），只是中间一步不同：
- 把共性部分保留在主方法里，变化点抽象为接口或函数式参数
- 比如订单创建、退款、补发都走类似流程，仅“生成单据”动作不同，就提取为 BillGenerator 接口
- 避免为了“统一”硬塞进一个超长 switch，也别在简单场景过早引入工厂模式
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
