我们都喜欢内聚，讨厌耦合（高聚合低耦合），关于内聚和耦合的标准建议是，设计应努力使内聚最大化并最小化耦合。这是一个很好的口头禅，但是在没有很好地理解真正意图的情况下，这常常是一种误导，或者被认为是学术上无关紧要的正确废话。
一个简单的特征是，耦合是系统中各个部分的互连程度，而内聚是这些部分内部互连的程度。
内聚聚合
要获得内聚，就需要希望组件要集中和明确定义，而不是被多重无关的职责所困扰。例如，继承层次结构的根通常应提供一个接口，它代表层次结构中所有子类都可以有意义地履行的职责。您应该尝试避免在层次结构的根接口中具有仅与某些子类相关但与其他子类无关的可选功能：这会使层次结构中的类使用和编写实现都尴尬。
对于类实现者，如果超类或基本接口提供的功能对于特定的子类而言没有意义，那么它们要么必须组成某种有意义的虚构行为，要么必须提出“不支持的功能”错误。无论哪种方式，在这样的层次结构中或周围都很难工作。
顺便说一句，您可能已经认识到这种特例是类层次结构的替代原理（准确地说是Liskov替代原理，或LSP）。有趣的是，LSP 也是在类型层次结构中最大化内聚力的特定应用。
耦合
那么，耦合如何？您希望组件是松散耦合的，而不是紧密耦合的。如果它们紧密耦合，则结果代码库的内部结构将交织在一起，微妙，难以理解，难以更改以及许多其他昂贵且笨拙的方法。
例如，当您需要更改表示形式时，即使用法是稳定的，让代码库的一部分依赖于偶然的数据表示决定也会使代码库的另一部分依赖。因此，将数据表示决策保密的通用建议是减少耦合的准则。
但是，不要太过分：低耦合并不意味着没有耦合。目标是减少而不是消除耦合：按照定义，没有耦合的系统不是系统。
耦合有多种形式，有些是显式的，而另一些是隐式的。例如，用Java的extends表示继承关系是一种显式耦合，或在C ++ 用includeC表示的文件依赖关系，这些都是直接声明并在代码中可见的依赖关系的示例。
但是，不要以为耦合的唯一形式就是显式的东西。许多年前，我遇到了一个团队，将整个系统的所有错误处理代码捆绑在一处，产生巧合的内聚，并将系统无关的部分耦合到相对不稳定的组件上。