高内聚低耦合源于清晰的职责划分：类应单一职责、主谓宾命名、方法同状态同修改动因；依赖须面向接口、构造器注入；行为应内聚于数据，用组合而非继承，杜绝硬编码与静态调用。
高内聚低耦合不是靠堆代码实现的，而是从职责划分开始的自然结果。核心在于：一个类只对一件事负责，且这件事能用一句话说清楚；它依赖什么、怎么被替换，必须清晰可见、无需猜测。
聚焦单一职责，用主谓宾句定义类
类名里出现“And”“Or”“Helper”“Manager”，或者你没法用一句主谓宾描述它的作用（比如“生成支付二维码”“校验用户手机号格式”），那它大概率已经超载。方法是否操作同一组状态、是否因同一原因修改，是判断内聚最实在的标准。
- OrderService 里混着 sendEmail() 和 exportToExcel()？这两个逻辑变化动因完全不同，应拆成 EmailNotifier 和 ReportExporter
- User 类里有 getFullName()、isValidEmail()、encryptPassword()？前两者属于领域行为，后者是安全基础设施，应移入 PasswordEncoder
- 右键 IDE 查看“Find Usages”，若被 Controller、定时任务、消息监听器各调用不同方法，说明它实际承担多个角色，该分了
依赖必须面向接口，且只通过构造器注入
类内部出现 new、static 单例、硬编码实现类名，都是耦合的明确信号。低耦合的本质是“我能换掉你，而不改我自己的代码”。
- 禁止 import com.xxx.service.impl.XxxServiceImpl；只允许 import com.xxx.service.XxxService
- 把 AlipayPayment 换成 WechatPayment，不应改动 OrderProcessor 源码，只替换构造参数或 Spring 配置
- 测试时能直接传 new MockUserRepository() 跑通，就说明依赖设计合格；若需启动数据库或 Redis，说明耦合已深入骨髓
把行为装进数据，别让 DTO + 工具类割裂语义
数据和行为分离是内聚杀手。UserDto + UserHelper 的组合看似解耦，实则让业务逻辑漂浮无根，难以追踪、无法复用、测试成本翻倍。
- user.isValidEmail() 比 UserHelper.isValidEmail(user.getEmail()) 更内聚——验证逻辑属于 User 本身的状态约束
- 订单状态转换 order.transitionTo(PAID) 应封装在 Order 类中，而不是散落在 OrderService 里一堆 if-else
- DTO 仅用于跨层传输（如 Controller → Service），不参与任何业务判断、格式化或校验
用组合代替继承，靠接口定义协作边界
继承绑定的是实现细节，组合绑定的是能力契约。没有真实“is-a”关系时强行 extends，等于给未来埋雷。
- 看到 if (type.equals("email")) sendEmail(); else if (type.equals("sms")) sendSms(); 就该提取 NotificationSender 接口，由 EmailSender、SmsSender 各自实现
- 业务类声明 private final PaymentProcessor processor; 构造器注入，不关心它是支付宝还是微信实现
- 避免在类内部 new 任何外部服务实例，也不调用 static 工具方法做核心业务逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
