高内聚Java类设计技巧分享

本文深入探讨了如何在Java开发中真正践行“高内聚、单一职责”原则——它不止于命名规范或方法数量控制，而在于每个类是否只专注一个清晰可定义、可独立测试与修改的抽象目标；文章通过类名填空法、动词领域一致性、构造函数与private方法中的隐性职责识别、IDE重构提示、单元测试命名反模式等实用技巧，揭示了职责蔓延的隐蔽陷阱，并尖锐指出Spring注解不等于职责合理，强调真正的设计难点在于需求变更时坚守边界——哪怕一行看似简单的调用（如发券），也可能悄然瓦解多年积累的架构健康度。

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

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

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

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

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

这类职责往往藏在 private 方法或构造逻辑里，比如一个本该只做数据转换的 OrderDtoMapper，内部却调用了 PriceCalculator.calculate() 并直接 new 了一个 DiscountService。

• 检查构造函数和初始化块：是否创建了不该由它管理的协作对象
• 搜索 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()，但这一行就让订单服务开始感知券系统了。

到这里，我们也就讲完了《高内聚Java类设计技巧分享》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！