应按变化原因而非代码量或技术分层拆分：字段操作不一致、依赖混杂、测试需 mock 多协议、业务分支多等信号表明职责混乱；新类命名须体现责任边界（如 ordervalidator），原类退化为流程协调者，通过接口和事件解耦。

直接按“谁会因为什么改它”来切，不是按代码行数或功能名字硬拆。一个上千行的类，已经不是难维护，而是随时可能出错。

先看变化原因，不是看方法名

别一上来就数方法个数。重点观察这些信号：

• 同一个类里，有的方法只读 orderItems，有的只写 statusLog——字段操作不一致，说明职责早就不统一
• 构造函数注入了 EmailService、PaymentGateway、InventoryClient 等多个无关依赖
• 写单元测试时，要 mock 超过 4 种协议（比如数据库、风控、短信、物流）
• 方法里大量出现 if (order.getType().equals("vip")) 或 switch (paymentMethod) 这类分支

按业务动作归类，不是按技术层切分

打开类，扫一眼方法名和字段名，把功能点映射到真实业务场景中：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• “用户注册”“密码重置”“邮箱验证”是一组，对应独立的用户生命周期动作
• “订单创建”“库存扣减”“优惠券校验”“积分发放”是另一组，但它们不该挤在同一个方法里
• 拒绝按“DAO/Service/Controller”这种技术分层来拆——那是部署视角，不是业务视角

新类命名要带责任边界，不能是工具感后缀

名字得让人一眼看出它管什么、谁会动它：

• ✅ OrderValidator：只响应合规规则变更（如身份证校验升级、地址格式调整）
• ✅ CouponValidator：只管有效性、叠加策略、黑名单，不调用外部服务
• ✅ InventoryDeductionHandler：只处理扣减逻辑，支持超卖策略切换
• ❌ 别叫 OrderUtil、PriceHelper、CommonService——这类名字掩盖了真实职责

原类退化为协调者，不掺和具体逻辑

原来的“上帝类”不要删，而是让它变轻：

• 重命名为 PlaceOrderUseCase 或 UserRegistrationFlow 这类流程名
• 只做三件事：接收参数、顺序委托、返回结果
• 不含任何 if/else、计算、异常转换；不直接调用 sendSms() 或拼 SQL
• 所有依赖都通过构造函数注入，类型明确（OrderValidator、CouponValidator…）

用接口+事件解耦，避免新旧代码互相拖累

拆完不是万事大吉，关键守住边界：

• 每个新职责定义清晰接口（如 EmailVerificationService），原类只持接口引用
• 新类之间不直接调用，改用事件协作（如 OrderCreatedEvent → 多个监听器各自执行）
• 拆一个，就删原类中对应逻辑，并加单元测试覆盖；旧代码加 @Deprecated 标记，约定下个迭代清除

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