回到基础：内聚和耦合第1部分

内聚和耦合是非常容易被误解的话题。

我们都听说我们的代码应该以这样一种方式来设计，以增加内聚性和松散耦合。是这样吗？两者都有可能实现吗？

让我们看一下什么是内聚和耦合，以便更好地理解它们与代码的关系。

什么是凝聚力？

内聚性仅仅是一个事物很好地结合在一起的性质。

如果某个事物有一个清晰的边界，并且所有的事物都包含在一个地方，那么我们可以说它是高度内聚的。

例如，棒球是非常有凝聚力的，组成棒球的所有东西都在一个小圆球里。

互联网没有凝聚力，很难界定，而且分散在各地。

在研究软件时，如果一个类或模块有明确的职责，并且该职责的所有实现紧密相连或在一个地方，那么我们认为它是高度内聚的。

软件中的一个很好的例子是将所有写入数据库的逻辑放在一个模块的一个类或几个类中，而不是让需要写入数据库的应用程序的每个部分在自己的类中实现该逻辑。

我们认为内聚是一件好事，因为它使软件更易于理解，减少了对系统某个部分的更改对系统其他部分的影响，并且允许我们在应用程序中重用代码。

什么是解耦？

解耦是一个事物不依赖于其他事物的性质。

我们可以说，如果某个事物只依赖于它自己，那么它是解耦的；如果某个事物有许多不同的依赖，那么它就是高度耦合的。

以iPod为例，它是高度解耦的，是一个非常独立的硬件，它有自己的电池，可以在不依赖任何其他东西的情况下运输。

现在考虑一下计算机中的主板。它没有解耦。它包含用于RAM、CPU、显卡等的特定插槽。如果这些组件的形状或种类发生变化，它们可能无法与主板一起工作。

在软件方面，如果一个模块或类对其他类或模块没有太多依赖性，我们可以考虑将其解耦。

考虑为链表数据结构实现一个类。这个类很可能是解耦的，因为它实际上不应该依赖于任何其他东西（除非你当然改变了你所认为的事物的粒度；后面会有更多的讨论）。

我们喜欢松散耦合的软件，因为它减少了一个模块中的更改对其他模块的影响，松散耦合的软件也更容易重用，因为它没有很多其他依赖项。

听起来他们在努力实现非常相似的目标

在大多数情况下，高内聚力和松耦合是相辅相成的。

如果您的类对位于该类中的那些职责的实现有明确定义的职责，那么很可能它将与系统的其余部分相当解耦。

在非常普遍的意义上，当你减少耦合时，你增加了内聚，反之亦然。

但是现在，我将在这里陷入泥泞，并质疑我们所说的“事物”或“模块”是什么意思。

在我的下一篇文章中，我将更深入地研究该主题，并探讨粒度如何影响内聚和耦合，并讨论它们实际上如何成反比。