2

我知道在某些情况下许多设计原则相互冲突。所以，我们必须权衡它们，看看哪一个更有益。直到现在我才知道 SRP 原则，并且完全基于它做了很多设计，但在内部，我在遵循这个原则时有时会感觉错了。现在我了解了 TDA，我的感觉得到了更多的支持 :)

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

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

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

我的设计到现在为止：-我一直在关注 SRP，在那里我有 AreaCalculatorService 类，它会询问形状状态并计算面积。这种设计背后的原因是形状不应该担心面积计算，因为它不是形状责任。但理想情况下，我曾经认为面积计算代码应该驻留在每个形状下，就好像如果出现新形状一样，我必须修改 AreaCalculatorService 类（这违反了扩展开放和修改关闭原则（OECM））。但总是优先考虑 SRP。这似乎是错误的

神话被打破了（至少我的）：-使用 TDA，看起来我的感觉是正确的，我不应该询问对象的状态，而是告诉形状来计算它的面积。虽然它会违反 SRP 原则，但会支持 OECM 原则。正如我所说的设计原则有时会相互冲突，但我相信行为完全取决于其对象状态，行为和状态应该是在一起的。

另一个例子：-假设我必须计算组织中所有员工的所有部门的薪水，那么我们应该遵循 SalaryCalculatorService 将依赖于部门和员工的 SRP。

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

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

4

1 回答 1

5

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

于 2016-11-06T17:09:18.600 回答