什么是内聚和耦合？设计时怎样取舍？

直接回答

内聚关注一个模块内部的职责是否围绕同一目标，耦合关注模块之间依赖了多少彼此的知识和变化。通常希望职责集中、依赖明确，使修改某个功能时不必牵动大量无关代码。但“高内聚、低耦合”不是类越小越好，也不是模块之间完全没有联系。

讲清原理

如果订单类既计算金额，又负责发短信、渲染页面和管理连接，往往承担了过多变化原因。把通知交给明确的协作者，订单逻辑就不必知道短信厂商的细节。

依赖接口可以减少对具体实现的依赖，但若接口仍暴露数据库表结构、厂商异常或大量内部步骤，耦合只是换了一个位置。真正需要观察的是改动传播范围、状态边界和协作协议。

例子与易错点

OrderService 依赖一个小的 Notifier 协议，比在多个方法中写死短信 SDK 更便于替换和测试。这里的改善来自协议收窄，而不只是多写了一个 interface。

不要用“拆成更多类”作为唯一指标。职责分散到十几个互相来回调用的类，同样可能难以维护。先让一个业务规则有清楚的归属，再决定依赖方向与抽象边界。

相关题：第 3 题、第 11 题、第 14 题。