design-patterns - 单一职责原则的范围是什么？它如何与 DRY 一起工作？

Question

我需要帮助澄清我对单一职责原则 (SRP) 的(错误)理解。

在我从事的许多项目中，我的同事认为 SRP 意味着一个类应该实现非常有限的功能，例如计算一组对象的总计。这导致具有一个公共(public)方法(一个职责)的类，例如计算总计(...)。我不是 DDD 专家，但据我所知，这会导致贫血领域模型、DTO 和无穷无尽的微服务。

采用这种方法并将 DRY 添加到组合中会导致在应用程序的不同部分重用这些类。

我倾向于在更高的层次上考虑 SRP，即需求层次。例如，报告需要计算总计，而税务相关计算则需要计算总计。在这种情况下应用 DRY 可能会导致意外错误。当由于报告要求的变化而需要改变总计计算逻辑时，如果我们应用了 DRY 并重用了该类，我们将打破我们的税收计算。

考虑到更改的原因应该仅作为需求更改的结果(我认为重构不适用于此处)，DRY 原则是否应该仅在单个用例中限定范围？

如果上面的说法是正确的，是否意味着我们不必将税收计算分解成一个单独的类？好吧，我们可以这样做来简化代码，但出于 SRP 的原因我们不会这样做吗？

我的想法错了吗？

Answer 1

单一职责原则到底说了什么？

The Single Responsibility Principle doesn't say that a class should implement very limited functionality, it says that there should only be one reason for a class to change.所以(至少就 SRP 而言)如果一个类只可能因为一个原因而改变，那么该类有很多方法是可以的。与所有这些原则一样，决定 SRP 是否适用(等效地，决定什么构成一个单独的类更改原因)是品味和判断的问题。

例如，在我刚刚链接到的 SRP 的原始描述中，我发现将 SRP 应用于玩具保龄球游戏是没有必要的——如果保龄球的规则发生变化，分离的类都会发生变化。另一方面，将几何计算与渲染 UI 分开应该对任何人都有意义。

我不知道你的代码库，但我觉得每个方法的类都是错误的。

SRP 与 DRY 有什么关系？

SRP 的反面是，如果两个类(class)因为相同的原因而改变(就像在那个保龄球比赛中)，也许他们应该是一个类(class)。这本身与 DRY 完全无关(它是关于责任的分散，而不是代码的重复)，但是:如果有人在编写或提取第二类时忘记了 DRY，你可能会注意到你何时更改两个类(或者，更糟糕的是，当你忘记更改一个并在生产中发现)并被提醒为什么 DRY 很重要。

我应该去重(“DRY up”)我的单独负责的类吗？

是的。相同代码的副本会导致错误。不要无理取闹；如果提取一些重复项会使您的程序更难理解并增加其代码行数，那么您肯定做得太过了。但是一定要提取重要的重复项，您只需测试一次并在它发生变化时更改一次。

但是，始终要明确提取的方法与需求之间的关系。如果您需要以相同的方式对某些值求和以进行报告和税收计算，请不要调用方法 totalForReporting 或将其称为 total 并将其放在您的 ReportingService，然后从您的 TaxService 中调用它——想要更改报告而不是税收计算的人不会考虑检查该方法是否在其名称不会出现的上下文中使用带领你期待。相反，将该方法称为类似 transactionTotal 的通用方法，或者只是将其称为 total 并将其放在您的 GeneralLedgerService 上，它将完全(咳咳) 清楚它的作用是什么，什么时候应该改变或不改变。

着眼于需求的重复数据删除将加强您的领域模型，因为您将始终小心地将代码与适当的领域概念相关联，无论是模型还是服务还是其他。