类拆分应依据变化原因而非功能或代码量，如字段操作不一致、注入无关依赖、测试需mock多协议、分支逻辑复杂等表明职责混杂；新类须按领域语义命名并明确边界，协调层PlaceOrderUseCase仅编排不处理逻辑。

核心是按“谁会因为什么改它”来切分，而不是按功能名字或代码行数硬拆。一个类该不该拆，关键看它有没有多个独立变化的原因。

从变化原因识别职责混杂

以下信号说明类已经越界：

• public 方法操作的字段完全不同：有的只读 orderItems，有的只写 statusLog
• 构造函数注入了 EmailService、PaymentGateway、InventoryClient 这类无关依赖
• 单元测试里要 mock 超过 4 个不同协议的接口（比如数据库、短信、风控、物流）
• 方法里频繁出现 if (order.getType().equals("vip")) 或 switch (paymentMethod) 这类分支逻辑

按领域语义而非动词命名新类

不要叫 OrderValidatorUtil 或 PriceHelper，而要用能体现责任边界的名称：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• OrderValidator：只响应合规规则变更（如身份证校验升级、地址格式调整）
• CouponValidator：只管优惠券有效性、叠加策略、黑名单，不调用任何外部服务
• InventoryDeductionHandler：只处理库存扣减逻辑，支持超卖策略切换，不碰订单状态字段
• PaymentCallbackRouter：只解析微信/支付宝回调参数并路由，不更新订单状态、不发通知

用协调层代替上帝类

原 OrderService 不应消失，而是退化为纯编排者，命名为 PlaceOrderUseCase：

• 只接收参数、顺序委托、返回结果
• 不含任何 if/else、计算逻辑、异常转换
• 所有依赖都通过构造函数注入，类型明确（OrderValidator、CouponValidator 等）
• 不直接调用 sendSms() 或 saveToDB()，而是委托给对应组件

避免伪拆分和常见陷阱

拆完仍出问题，往往是因为没守住边界：

• 别把 OrderValidator 写成静态工具类——它需要可替换，比如测试时注入宽松校验规则
• CouponValidator 不应自己查数据库，而是通过 CouponRuleProvider 接口获取策略
• OrderRepository 里不拼 SQL 字符串，用 QueryDSL 或预编译语句封装方言细节
• 拒绝“服务链式调用”（A→B→C），改用事件解耦：OrderCreatedEvent → 各处理器监听执行

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