告诉，不要问

关于规则和原则

前段时间，我写了关于德米特法则的文章 ，关于遵守该法则的好处。 今天我想写关于
“告诉，不要问”的原则。 至少在我看来，该原则是所提及法律的起点。 遵循LoD是应用TDA原则的后果之一。

好的，但是我们应该告诉什么，我们也不应该问什么？

要求结果，而不是数据

简而言之，TDA原理告诉我们，与其询问对象数据，不如告诉他们应该做什么，然后等待操作结果。

这意味着代替：

Age age = sebastian.getAge();
if (age >= 18) {
    letDoTheThingsThatAdultsDoes(sebastian);
}

我们应该这样写：

if (sebastian.isAdult()) {
    letDoTheThingsThatAdultsDoes(sebastian);
}

现在好点了吗？ 容易阅读吗？ 了解代码的含义？

不幸的是，哪种解决方案并不总是很明显。

你说的越多，更大的物体就会变成……

上面的示例很好地展示了TDA原则应该保护的内容。 我说的是封装。

我们没有从对象中提取数据。 我们不让外界知道它们。 我们没有直接对其进行研究。 相反，我们告诉对象必须执行的操作，然后等待结果。

毕竟，使用对象自己的属性操作不是对象的责任吗？

但是，您不能太渴望。 封装很重要，但是对于对象来说，拥有适当的API也同样重要。 允许舒适工作的API。

您能想象如果我们禁止创建从对象中提取数据的方法会发生什么情况？ 如果我们将此原则变为法律，将会发生什么？

你应该总是“讲”吗？

每个附加操作都是另一行代码。 这是另一项责任。

这些职责是围绕一个特定的上下文（特定的对象）组织的，但是……对于单个对象来说，不是太多吗？

如果严格按照TDA原则编写代码，则可能会遇到两个主要问题。

首先，课程开始发展壮大，结果，课程变得非常庞大。 如果不惜一切代价进行封装成为您的妄想症，则您可能会发现自己处在类代码行数不胜枚举且代码难以理解的地方。

其次，越来越多的依赖关系和责任往往与大类并驾齐驱。 是的，代码是围绕特定对象的属性组织的，但是其许多方法没有任何共同的部分。

这就是为什么您需要关心对象的大小并保持对象尽可能小。 拥有提供行为并保护数据的对象是很好的。 但是您必须记住，过多的行为会导致过多的责任。 这直接影响您的类和应用程序的复杂性。

当有不止一个...

在特定操作需要来自几个不同类型的不同对象的数据的情况下又该怎么办？

让我们简化问题！ 我们来谈谈需要来自同一类的不同对象的数据的计算。 一个简单的示例可以是一组人的平均年龄的计算，其中每个人都是单独的对象。

我们应该怎么做？

我们是否应该要求年龄：

Age totalAge = Age.NEWLY_BIRTH;

for (Person person : persons) {
    totalAge = totalAge.add(person.getAge());
}

return totalAge.divide(persons.size());

或者，也许我们应该开始思考如何通过告诉对象我们想要什么来解决这个问题？

摘要

如您所见，“告诉，不要问”的原则不能被视为经验法则。

在将数据从对象中提取到外部世界之前，我们始终应牢记封装并至少考虑两次。 但是，我希望本文向您显示有时是必要的。

对于那些想了解更多有关“告诉，不要问”原则的人，这里有很多有用的链接：

• http://martinfowler.com/bliki/TellDontAsk.html
• http://c2.com/cgi/wiki?TellDontAsk
• http://coding-is-like-cooking.info/2013/05/tell-dont-ask-object-oriented-design/
• https://pragprog.com/articles/tell-dont-ask

翻译自: https://www.javacodegeeks.com/2015/11/tell-dont-ask.html