《C++代码整洁之道：C++17 可持续软件开发模式实践》 —3.6　高内聚原则

3.6　高内聚原则

软件开发中的一条通用建议是，任何软件实体（如模块、组件、单元、类、函数等）应该具有很高的（或强的）内聚性。一般来讲，当模块实现定义确切的功能时，应该具有高内聚的特性。

为了深入研究该原则，让我们来看两个例子，这两个例子没有太多的关联，从图3-1开始。

图3-1　MyModule类有很多的职责，这就导致了模块相互依赖

在上面的例子中，模块随意划分，业务领域三个不同的功能放在了一个模块内。功能A、功能B和功能C之间基本没有什么共同点，但是这三个功能却被放在MyModel模块中。阅读模块的代码就会发现，功能A、功能B和功能C在不同的、完全独立的数据上运行。

现在，观察图3-1中所有的虚线箭头，箭头指向的每一个模块都是一个被依赖者，箭头尾部的模块需要箭头指向的模块来实现。在这种情况下，系统中的其他模块想要使用功能A、功能B或功能C时，调用的模块就会依赖于整个MyModule模块。这样设计的缺点是显而易见的：这会导致太多的依赖，并且可维护性也会降低。

为了提高内聚性，功能A、功能B和功能C应该彼此分离（见图3-2）。

图3-2　高内聚：将之前混合在一起的A、B、C分离成不同的模块

现在，很容易地看出，每个模块的依赖项比旧的MyModule的依赖项少得多。很明显，模块A、模块B、模块C之间没有直接的关系。Module1是唯一依赖模块A、模块B和模块C的模块。

另外一个低内聚的形式是***反模式（Shot Gun Anti-Pattern）。我想大家应该都听说过，霰***是一种能发射大量小铁沙的武器，这种武器通常有很大的散射性。在软件开发中，这种隐喻用于描述某个特定领域方面或单个逻辑思想是高度碎片化的，并且分布在许多模块中，图3-3描述了这种情况。

在这种低内聚方式下，出现了许多不利的依赖关系，功能A的各个片段必须紧密结合在一起。这就意味着，实现功能A子集的每个模块必须至少与一个包含功能A子集的模块交互。这会导致大量的依赖***叉。最坏的情况是导致循环依赖；比如，模块1和模块3之间，或模块6和模块7之间。这再一次对可维护性和可扩展性产生了负面影响。当然，这种设计的可测试性也是非常差的。

这种设计将导致所谓的“霰***手术”。对功能A的某种修改会导致很多模块进行或多或少的修改，这真的很糟糕，并且应该避免。我们应该把与功能A相关的所有代码都拿出来，把相同逻辑的代码放到一个高内聚的模块内。

一些其他的原则—例如，面向对象设计的单一职责（SRP）原则（详见第6章），会促进高内聚性。高内聚往往与松耦合相关，反之亦然。

图3-3　功能A跨越了5个模块