高内聚低耦合是可落地的设计习惯：一个类只专注做好一件事（高内聚），同时尽量少依赖别的类、也不让别的类过度依赖它（低耦合）；体现为单一职责、接口注入、组合优于继承、测试易mock等具体实践。
高内聚低耦合不是抽象口号，而是可落地的设计习惯：一个类只专注做好一件事（高内聚），同时尽量少依赖别的类、也不让别的类过度依赖它（低耦合）。
高内聚：聚焦“自己该干的事”
核心是单一职责——类内部的属性和方法都围绕同一目标服务。比如一个 UserValidator 类，只负责校验用户字段（邮箱格式、密码长度、手机号合法性），不处理数据库保存、不发短信、不生成 token。
- 如果发现一个类里有
if (type.equals("email"))或switch (format)处理多种类型逻辑，大概率已违反高内聚 - 方法也应高内聚：一个方法最好只完成一个明确动作，比如
formatDate()就只做格式化，不顺带记录日志或校验空值 - 工具性逻辑（如脱敏、加解密、日期转换）要抽成独立类，别塞进业务类里
低耦合：控制“跟谁打交道、怎么打交道”
关键在减少类之间的强依赖。不是“完全不依赖”，而是用松散、可控的方式协作。
- 依赖必须通过构造函数或 setter 注入，且类型为接口（如
OrderRepository），而非具体实现（如JdbcOrderRepository） - 避免跨层持有底层对象：Service 层不该直接 new
JdbcTemplate，Controller 不该直接操作RedisTemplate - 减少类内部对其他类的直接调用，尤其避免硬编码、静态单例、全局变量
- 测试时若需 mock 超过 3 个协作对象，说明这个类承担了太多角色，该拆分了
用组合代替继承，让关系更清晰
继承容易把父类的实现细节、字段、方法签名一并绑定进来，改父类可能悄悄破坏子类行为。而组合更直观可控：
- 比如 OrderService 需要发通知，就持有一个
NotificationSender接口，运行时注入EmailSender或SmsSender - 这样替换通知方式无需动
OrderService，新增渠道也只需加个实现类，不碰原有逻辑 - 适配器模式、策略模式都是组合思想的典型体现
从代码结构看是否达标
可以快速自检几个信号：
- 类名能否用一句话说清职责？例如“解析 JSON 为 User 对象”“将订单状态更新为已支付”
- 修改这个类时，是否经常要同步改其他五六个类？如果是，耦合可能过紧
- 单元测试中，是否能轻松传入模拟实现（如
new MockUserRepository()）来隔离外部依赖？ - 包结构是否按功能分层（如
order、notification、common），而不是按技术分（如controller、service、dao）？后者容易导致横向职责分散
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
