“高凝聚力”是“单一责任原则”的同义词吗

Question

高凝聚力是单一责任原则的同义词吗？如果没有，它们有什么不同？

Answer 1

这不是同义词。SRP（单一责任原则）是你确保你的类只有一个责任的时候。这肯定会增加你的类的凝聚力。

但是，您可以在不严格遵循SRP的情况下获得高内聚性。

这里有一个很好的来源。

Answer 2

这不是一回事。

你可以拥有一个高度内聚的班级，而不仅仅是一个单一的职责。

Answer 3

你问：如果不是，它们有什么不同？

抛出你认为你猜测这个原则意味着什么。

Robert C. Martin将这一原则正式定义为：

一个类应该只有一个改变的理由

大多数人对SRP的定义是不正确的。SRP通常被错误地解释为：

“员工类不应该UpdateDemographics（）和SendMessage（），这两项职责都算作两项职责……将SendMessage（）放入Message类中！！”

^^错了

对

罗伯特·C·马丁说

“责任不是‘代码所做的事情’”。（NDC 2012）

Robert C.Martin将SRP定义为：

“任何模块都应该只对一个人负责—[角色]。”（NDC 2012）

当利益相关者要求更改视图中的数据排序时，管理层不应该害怕并担心算法会崩溃。因为处理视图排序的模块只对利益相关者负责，处理总计算算法的模块只对业务分析师负责。所以当业务分析师要求更改算法时，我们不应该害怕视图会改变。

因此，一个模块（单数）的更改只有一个原因：该模块所服务的单人角色请求更改。

有了这个作为SRP定义的新基础，您现在可以应用您以前认为SRP是什么，并使定义更加细粒度。没有人说要把所有的前端代码放在一个模块中，把所有的后端代码放在一个模块中。

假设你有一个方法<代码>十进制计算（员工）和另一个方法<代码>作废工资（员工）

这些是属于一起的吗？可能会有一个执行各种计算的服务，也可能有一个只做包装人力资源支付SOAP的服务。也许Pay（Employee）调用了calculatePay（Employee），但仅仅因为他们有Pay（Employee）这个词，并不意味着他们属于一起！

我如何创造凝聚力？-你没有。凝聚力是你观察到的东西。你要做的就是不要把属于你的东西拆开。

你可以为你想要的每个公共方法创建一个类。每个类现在都有一个公共方法，一切都是定义良好的混乱。你有名为PayrollClass1和PayrollClass2的类，因为一个是单向计算，另一个是双向计算。

有些语言甚至可以从类的完全缺乏中获益，方法可以免费运行。没有方法分组，方法只是可以随时调用的方法。它们几乎都是静态的。

然而，你可以观察到，CalculatePayFor（Employee）和Pay（Employee）实际上是高度受限的。他们就像一对完美无缺的夫妻，他们在一起看起来很棒。当方法明确地属于一起时，你不想把它们分开。观察它们的自然状态，建立野生动物保护区。这就是保持高度的凝聚力。你不是创造它，而是观察它。

这真正有助于正确的代码复制。例如，PayrollService。CalculatePayFor（Employee）与ReportService的代码完全相同。计算（员工）。这不好吗？当然不是。如果高级管理层为了报告而要求更改员工薪酬的计算，这与H.R.为了税务目的要求您更改实际支付方式的计算是不同的责任。

“等等，他是不是把SRP和Cohesion搞混了？”不，但我很高兴你认识到了这一点。如果ReportService进入PayrollService的类并使用它的方法呢？然后当它为了合法的支付目的而改变时，报告都改变了......但是管理层不想这样！！！所以由于Cohesion强制方法保留在自己的类中，SRP强制模块在应用程序中保留在自己的类中，ReportService被迫从PayrollService类复制/粘贴方法。现在它们可以相互独立地改变了。

“但如果这不是你想要的呢？”嗯，代码中有很多地方不允许重复。但最常见的情况是算法保持自身不变，并独立于依赖项进行更改。即使这意味着重复。这取决于需要什么。但关注点分离、单一责任、凝聚力和干涸（不要重复自己）都是不同的想法。

补充说明：DRY并不意味着永远不会有重复。正如我提到的：很多时候你会有重复的代码，因为不同的关注点之间的业务规则是相似的，并且有不同的原因要改变。