问题标签 [tell-dont-ask]

请告诉我，如果我在这个例子中以正确的方式应用Tell, don't ask原则。

我有两个类，CalculationResults有一个函数calculateMe()，用于Data进行一些计算。重要的是它存储结果。

这段代码的第一个版本（在应用Tell 之前，不要问）没有使用Data::calculate函数，但它有一个getterfor dataForCalculations，所以我在某个地方调用了calculationResults.calculateMe(data.getDataForCalculations()).

新版本更好吗？

我正在用 Java 做一个项目，它有很多需要多个返回对象的方法。为此，我必须继续创建封装返回对象的私有类。这些对象是有意义的，因为我的代码中的 FontResult 将返回字体名称和字体大小，例如，但不断为我需要的每种返回类型创建新对象感觉是错误的，并且不知何故就像我试图规避 Java 的编写方式一样。这是错误的还是这样做可以吗？我应该以更多的方式来构建我的代码吗？

一个例子如下：

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

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

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

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

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

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

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

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

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

我正在尝试遵循一些更流行的设计原则，包括 SOLID 和领域驱动设计。我的问题是关于人们如何处理“初始化”域对象。

这是一个简单的例子：

基于SOLID，我不应该依赖混凝土，所以我创建了一个接口和一个类。由于我正在利用领域驱动设计，因此我使用相关方法创建了一个对象。（即不贫血）。

为了帮助测试和更松耦合，我还使用 IoC 容器来创建本书。所以当这本书被创建时，它总是被创建为空的。但是，如果一本书没有 ISBN 和 Inventory，则它是无效的。

我可以有 4 或 5 个使用 BookstoreBook 的不同类。一方面，

任何方法如何知道得到一本有效的书？我下面的解决方案似乎违反了“告诉不要问”的原则。

a) 每种使用书店书籍的方法都应该测试有效性吗？（即需要NeedToIncreaseInventory 测试书籍的有效性？我不确定它应该知道什么使BookstoreBook 有效。）

b）我是否应该在 IBookstoreBook 对象上有一个“CreateBook”，并且只是“假设”客户知道他们必须在他们想要初始化 BookstoreBook 的任何时候调用它？这样，NeedToIncreaseInventory 就会相信 BookstoreBook 上已经调用了“CreateBook”。

我对这里推荐的 appreach 感兴趣。

请查看以下代码：

我们发现大多数消费者首先调用 IsCultureSupported 来验证他们的文化是否受支持。如果不支持文化，他们会调用 GetFallbackCulture()：

根据单一职责原则（和其他 OOP 规则），是否可以引入一个功能（在 ICultureService 及其实现中），例如：

这在 BAD 和 GOOD 用法中展示了整体。

这doItBAD()很糟糕，因为传递一个对象对于函数来说是不必要的知识，但 MEMORY-GOOD，因为它只是传递一个引用，而不是整个数组本身

这doItGOOD()很好，因为它只传递一个数组，但 MEMORY-BAD，因为它只传递所有数据而不是引用。

现在如何决定使用哪一个？