问题标签 [tell-dont-ask]

Information-Expert、Tell-Don't-Ask和SRP通常作为最佳实践一起被提及。但我认为他们是矛盾的。这就是我要说的。

支持 SRP 但违反 Tell-Don't-Ask & Info-Expert 的代码：

支持 Tell-Don't-Ask 和 Info-Expert 但违反 SRP 的代码：

请告诉我这些做法如何和平共存。

术语的定义，

• 信息专家：具有操作所需数据的对象应承载操作。

• Tell Don't Ask：不要为了工作而向对象索取数据；告诉对象做这项工作。

• 单一职责原则：每个对象都应该有一个狭义的职责。

I'm trying to model a basic scenario involving a Person and a Seat. A Person has a Status property: Sitting or Standing. A seat has a Seated property that specifies the Person that is currently sitting in it. Also, a Seat is special in that it only "accepts" certain people to sit in it. I know it sounds strange for a Seat to "accept" someone, but just imagine it prefers certain people over others.

Following "Tell, Don't Ask," How should I design the Person and Seat objects so that a Person can sit down in a Seat only when the Seat "accepts" him and also have his status changed to Sitting. My first thought was that a Person should have a SitDown method as follows:

But this seems like it would require the Person class to inspect the state of the Seat before sitting in it, as well as having to update the Seat's Seated property (instead of the Seat updating the property itself):

It seems better to have the Seat class handle seating a person:

But this still requires the Seat to change the person's status. Is this the way that the person's status should be updated? Should only a Person be able to change his status? How would you model this simple scenario?

不知何故，这些年来我一定忽略了“告诉，不要问”OOP 原则，因为我几天前才第一次了解它。

但是上下文是关于验证代码的讨论，该代码已从 ASP.NET Web 表单页面移到数据/业务对象中，并且没有“Validate()”方法，只是一个本身进行验证的保存方法和（据说）引发了异常。我问为什么要这样设计，我被引导到 OOP 的“告诉，不要问”原则，这是我从未听说过的，所以我们一起研究了 Google，我立即受到了教育。;)

仍然，有些东西闻起来不对劲，是否应该在数据从用户手中转移到处理和/或收集数据的业务层之前对其进行清理，而不是反过来？我很困惑这如何促成好的设计。

似乎“告诉，不要问”的规则与您不应该向目标对象询问目标对象状态的想法有关，并且该原则从未真正适用于传递给目标对象。

假设我有两个对象：

目前我有这样的事情：

它检查表是否可映射，然后映射它，但还必须检查空表。

这样做是否更有意义：

这样表就负责检查它自己的状态和任何检查，然后创建一个新的地图。

编辑：更多信息

我还有一个 MapTables 方法，它采用一组表，因为一个地图可以包含许多表，例如：

这是否意味着我应该将 map 命令保留在 Map 类型上。

你怎么看？

如果我不想公开我的对象的状态，但我仍然需要显示它（比如说在 HTML、XML 或 JSON 中），我将如何在 MVC 环境中执行此操作。有一个导出方法来导出一个简化的不可变对象（如果你愿意的话，一个“数据类”）是否有意义。添加与接口对话的渲染方法怎么样？有没有其他方法可以解决这个问题？

在以下简单场景中，您将如何坚持“告诉，不问”原则（以下简称“原则”）？在俄罗斯方块游戏中，我有与以下示例相关的 Board、BlockGrid 和 Piece 类：

一旦fallingPiece 放置在BlockGrid 的底行，它就不再是“fallingPiece”了。我是否正确，我没有违反以下原则？

但这与我认为明显违反原则的情况真的不同吗？

我并不是假设我已经以正确的方式设计了这些类关系以使用该原则。如果那是我所缺少的，请就替代设计提出建议。

编辑，建议的解决方案：

我通过事件提出了“命令反馈”的答案。Board 告诉 BlockGrid 移动一块。BlockGrid 的 movePiece 方法根据结果调度 MOVED_TO 或 MOVE_FAILED 事件，Board 可以监听并使用这些事件来确定一块是否已停止下降。请随时提供有关此解决方案的反馈。

在这个简单的例子中（当然我的现实世界的问题要复杂一点，虽然基础是一样的），我如何强制告诉不要问到最大？我想最大限度地告诉不要在过程方法中询问，在当前状态下，它更难模拟和测试。

编辑：更新样本更多 DIish

我想在控制台上打印一个战士的描述，其中包括战士的力量和战士的武器，格式This <description> warrior uses a <weapon>为例如：This strong warrior uses a butter knife.

为清楚起见进行编辑：我想这样做而不是通过使用 getter 或任何其他方法（如 toString）来向对象询问数据，这揭示了对象的内部实现。我也想在不将我当前的 UI（控制台）硬编码到对象本身的情况下做到这一点。

避免吸气剂

我可以通过对 UI 进行硬编码来避免吸气剂：

避免硬编码的 UI

我可以通过使用 getter 来避免硬编码的 UI：

可以避免两者吗？在上面的例子中我该怎么做？

注意：为了响应一些初步的答案，getter 不是遵循命名约定的方法getSomeFieldName。因此，重命名getSomeFieldName为aMethodThatIsNotPrefixedByGet不是解决方案。getter 是一种将私有数据从对象传递到调用它的作用域的方法。

完全清楚的是，我在这里要处理的问题与数据封装有关（因为这个问题被标记了）。如何防止将数据传递给不需要知道该数据的对象并且仍然避免对 UI 进行硬编码？

此外，基于这些 问题 ，我认为不应以许多答案所建议的方式使用 toString 。toString 似乎用于生成对象的文本表示以进行调试等，而不是用于返回任意输出，尤其是不用于返回依赖于应用程序的输出。

我有一个工厂类，它根据接收到的参数创建一个对象。参数是一个标识符，告诉它应该创建哪个对象。它的第一步是使用数据访问层为对象提取信息。下一步是对数据进行一些清理/转换。最后，它创建所需的对象并返回它。

我想确保清理/转换步骤顺利，但它返回的对象没有暴露任何状态，所以我不确定如何轻松测试它。

数据访问层和数据库结构不能改变，因为它们必须使用遗留代码。

在对象被使用后，我可以在系统中进一步测试它，但这会导致难以维护的大型测试。

我还考虑过公开对象的状态，或者将责任放在另一个类中并对其进行测试，但这两个选项似乎都在更改测试系统。

关于其他方法来测试这样的东西有什么想法吗？

I think the issue is explained best with an example.

I like this pattern, because it's very cohesive. Action interfaces are paired with their Services. Business logic is not cluttered in many classes. Subclasses are only providing data to the action and don't have to be busy. I adopted it from here ( http://jamesladdcode.com/?p=12). The problem is that i didn't found a good solution for testing the behavior in the "doTheHardBusinessStuffWith(Object whatever)" method if i mock the otherService. With the mock i have to care how the business method gets called. But how can i do this. I use mockito and tried it with a ArgumentCapture already. But it don't feels right because of abusing ArgumentCapture.

I would like to know if the pattern used in class MyService.myBusinessStuffFor(int id) has a name (is it strategy pattern)? But my major questions is how to make this code testable with mock of OtherService?