职责单一的类应只做一件可清晰定义、独立测试和修改的事；判断标准是类名替换为“负责……的类”后，所有public方法都自然属于该省略内容，且避免混用不同领域动词、私有方法中隐藏协作逻辑、构造函数中创建业务对象等破绽。

职责单一的类不是靠名字里带“Manager”“Helper”“Utils”来体现的，而是看它是否只做一件事，并且这件事能被清晰定义、独立测试、独立修改。

一个类该有多少个 public 方法才算单一职责？

没有固定数量，关键看这些方法是否服务于同一抽象层次的同一目标。比如 UserRepository 有 save()、findById()、deleteById() 是合理的——它们都围绕“持久化用户”这一职责；但如果它还包含 sendWelcomeEmail() 或 validatePasswordStrength()，就明显越界了。

• 判断标准：把类名换成“负责……的类”，填空后所有 public 方法都应自然落在这个省略号里
• 常见破绽：方法名里混用不同领域动词（如既有 parseJson() 又有 logError()）
• IDE 提示可辅助识别：IntelliJ 的 “Extract Class” 快捷键（Ctrl+T）常会建议拆分，说明当前类已有隐性职责分裂

如何识别并剥离“悄悄多出来的职责”？

这类职责往往藏在 private 方法或构造逻辑里，比如一个本该只做数据转换的 OrderDtoMapper，内部却调用了 PriceCal

• 检查构造函数和初始化块：是否创建了不该由它管理的协作对象
• 搜索 new 关键字：如果新建的是业务类（非 DTO、Exception、Collection 等基础类型），大概率是职责入侵
• 看单元测试命名：如果一个测试类要 mock 三类不同服务（支付、通知、库存），说明被测类正在协调多个领域

为什么 @Service + @Component 不等于职责单一？

Spring 的注解只解决“交给容器管”，不解决“这个类该管什么”。很多 @Service 类实际承担了参数校验、DTO 转换、事务边界、重试逻辑、日志埋点五种职责，只是因为都在一个 @Transactional 方法里，看起来“很连贯”。

• 典型信号：方法体内出现 if (xxx == null) throw new IllegalArgumentException() —— 校验不该由 service 层兜底
• 更安全的做法：用 record 或构造函数强制校验（如 OrderId.of(String)），让非法状态根本构造不出来
• 事务控制粒度：一个 service 方法里调用三个外部 API 并统一回滚？不如拆成三个小事务 + 补偿逻辑，每个只专注一件事

真正难的不是写出单一职责的类，而是在需求变更时守住边界——比如运营要求“下单成功后自动发券”，最容易的改法是在 OrderService.create() 末尾加一行 voucherService.issue()，但这一行就让订单服务开始感知券系统了。