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

Question

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

在我从事的许多项目中，我的同事认为 SRP 意味着一个类应该实现非常有限的功能，例如计算对象集合的一些总数。这导致类具有一种公共方法（一种责任），例如CalculateTotals(...)。我不是 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 的反面是，如果两个班级因相同的原因（如在保龄球比赛中）发生变化，也许它们应该是一个班级。这本身与 DRY 根本无关（这是关于责任的分散，而不是代码的重复），但是：如果有人在编写或提取第二个类时忘记了 DRY，您可能会在更改时注意到两个类（或者，更糟糕的是，当您忘记更改一个并在生产中发现时）并被提醒为什么 DRY 很重要。

我应该对我的单独负责的班级进行重复数据删除（“干掉”）吗？

是的。相同代码的副本会导致错误。不要无理取闹；如果提取某些重复项使您的程序更难理解并且增加了它的代码行数，那么您肯定做得过火了。但是请务必提取大量重复内容，您只需对其进行一次测试并在更改时更改一次。

但是，请始终明确提取的方法与需求的关系。如果您需要以相同的方式对某些值进行汇总以进行报告和税收计算，请不要调用方法 totalForReporting 或将其称为 total 并将其放在您的 ReportingService 上，然后从您的 TaxService 调用它 - - 想要更改报告而不是税收计算的人不会考虑检查该方法是否用于其名称不会让您期望的上下文中。取而代之的是，将该方法称为transactionTotal 之类的通用方法，或者将其称为total 并将其放在您的GeneralLedgerService 上，它将完全（咳咳）清楚它的作用是什么以及何时应该改变。

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