据我所知，在某些情况下，许多设计原则相互冲突。因此，我们必须权衡它们，看看哪一个更有益。 直到现在我才意识到SRP的原理并且完全根据我的设计做了很多设计，但在内部我感觉有时候错了 这个原则。现在我开始了解TDA，我的感觉得到了更多支持：）
SRP： - 对象应该担心自己的问题而不是其他任何人
TDA： - 行为（仅依赖于其对象状态）应保留在对象本身内
示例： - 我有不同的形状，如矩形，方形，圆形等。现在我必须计算面积。
我的设计到现在为止： - 我正在关注SRP，我在那里使用了AreaCalculatorService类，它会询问状态并计算区域。这个设计背后的原因 形状不应该担心面积计算，因为它不是形状责任。但理想情况下，我曾经认为区域计算代码应该位于每个形状下 如果新的形状出现，我必须修改AreaCalculatorService类（违反Open for extension和closed for modification principle（OECM））。 但总是优先考虑SRP。这似乎是错误的
神话被破坏了（至少是我的）： - 使用TDA，看起来我的感觉是正确的，我不应该询问对象的状态，而是告诉形状计算它＆＃39;区域。虽然 它将违反SRP原则，但将支持OECM原则。正如我所说，设计原则有时相互冲突，但我相信哪里有行为 完全依赖于它的对象状态，行为和状态应该在一起。
另一个例子： - 说我必须计算一个组织中所有员工的所有部门的工资，然后我们应该按照SalaryCalculatorService的SRP 将取决于部门和员工。
它会询问每位员工的工资，然后对所有工资进行总结。所以我在这里要求的是员工状态 仍然没有违反TDA calcSalary不仅仅依赖于每个员工的工资。
让我知道，如果我对这两个原则的解释是正确的，我应该在第一种情况下遵循TDA而在第二种情况下遵循SRP吗？
答案 0 :(得分：4)
我认为您的TDA理解是正确的。
问题在于SRP，根据我的经验，它是最容易被误解的SOLID原则。
SRP说一个班级应该只有一个改变的理由。 “改变的原因”部分经常被混淆为“它应该只有一个责任”，所以“它必须只做一件事”。不，这不是那样的。
“改变的原因”完全取决于类所在应用程序的上下文。特别是它取决于与软件交互的参与者，并且将来能够要求改变
演员可以是：支付软件的客户，普通用户和一些超级用户。将管理应用程序数据库的DBA或处理运行应用程序的硬件的IT部门。一旦你列举了软件周围的所有演员，为了遵循SRP的说法，你必须以一种只有一个责任的方式编写你的课程，因此只有一个演员的请求可能需要对你的课程进行一些更改。
因此，我认为您应该遵循TDA将使用这些数据的数据和行为放在同一个对象中。通过这种方式，您可以管理对象之间的关系，告诉他们该做什么而不是询问数据，减少耦合并达到更好的封装。
如上所述，SRP将指导您决定将哪些行为放在一个对象而不是另一个对象中。