oop - 单一职责 (SRP) 与告诉不要问 (TDA)？

Question

我知道许多设计原则在某些情况下是相互冲突的。因此，我们必须权衡一下，看看哪一个更有利。到目前为止，我已经了解了 SRP 原则，并且仅根据该原则进行了很多设计，但在内部，我在遵循 SRP 原则时有时感觉错误这个原则。现在我开始了解TDA，我的感觉得到了更多的支持:)

SRP:-对象应该担心自己的问题，而不是其他人

TDA :- 行为(仅取决于其对象状态)应保留在对象本身内部

示例:-我有不同的形状，如矩形、正方形、圆形等。现在我必须计算面积。

到目前为止我的设计:-我遵循SRP，其中我有AreaCalculatorService类，它将询问形状状态并计算面积。这个设计背后的原因形状不应该担心面积计算，因为它不是形状的责任。但理想情况下，我曾经认为面积计算代码应该驻留在每个形状下就好像如果出现新形状，我必须修改 AreaCalculatorService 类(这违反了开放扩展和关闭修改原则(OECM))。但始终优先考虑SRP。这似乎是错误的

神话被打破了(至少是我的):-有了TDA，看起来我的感觉是正确的，我不应该询问物体的状态，而是告诉形状来计算它的面积。尽管它会违反SRP原则，但会支持OECM原则。正如我所说，设计原则有时会相互冲突，但我相信行为在哪里完全依赖于它的对象状态，行为和状态应该在一起。

另一个例子:-假设我要计算一个组织中所有员工的所有部门的工资，那么我们应该遵循SRP，其中SalaryCalculatorService将取决于部门和员工。

它会询问每个员工的工资，然后对所有工资进行求和。所以我在这里询问员工的状态但是仍然没有违反 TDA calcSalary 不仅仅取决于每个员工的工资。

请告诉我我对这两个原则的解释是否正确，在第一种情况下我应该遵循 TDA，而在第二种情况下应该遵循 SRP？

Answer 1

我认为您对 TDA 的理解是正确的。问题出在 SRP 上，根据我的经验，它是最容易被误解的 SOLID 原则。SRP 说，一个类应该只有一个改变的理由。 “改变的原因”部分经常与“它应该只承担一项责任”因此“它必须只做一件事”相混淆。不，不是那样的。
“更改的原因”完全取决于类所在的应用程序的上下文。特别是它取决于与软件交互的参与者，并且将来可以请求更改。
参与者可能是:为软件付费的客户、普通用户和一些 super 用户。管理应用程序数据库的 DBA 或处理运行应用程序的硬件的 IT 部门。一旦您枚举了软件周围的所有参与者，为了遵循 SRP 的规定，您必须以一种只有一个职责的方式编写您的类，因此只有来自一个参与者的请求可能需要对您的类进行一些更改.
因此，我认为您应该遵循 TDA 将数据和使用这些数据的行为放在同一个对象中。通过这种方式，您可以管理对象之间的关系，告诉它们要做什么，而不是询问数据，减少耦合并达到更好的封装。
如上所述，SRP 将指导您决定将哪些行为放入一个对象而不是另一个对象中。