oop – 告诉,不要求和单一责任 – 用课堂上的数据做新事物

每当设计软件时,您都必须平衡不同的原则,因为它们中的许多原则相互冲突.例如,DRY(Do not Repeat Yourself)原则往往与单一责任原则相冲突,特别是当两件事情相似但并不完全一样的时候.

通常你必须决定哪个原则比较重要,并强调这个原则超过另一个原则(尽管你应该尝试尽可能多的遵守).通常情况下,原则在一起工作,有时他们会相互作用.

在这种情况下,告诉不要问其他原则,如Law of Demeter(尽管它的名称仍然是一个原则,就软件而言,更好地描述为最不了解的原则).

LoD告诉我们的是,一个对象的方法只能调用其他方法

>自己
>作为参数传入的对象
>通过参数传递的对象创建/实例化的任何对象
>对象直接组件对象
>或全局变量

没有具体说明,但是我觉得选择方法调用的优先级顺序应该是顺序的,全局变量是最后的.但是,这不是在这里和那里.

所以,如果我们结合Tell,不要询问与LoD,那么将对象传递给另一个“询问”对象是完全可以的.意思是说,你有一个Analysis对象,你可以“告诉”做某事,把DataSet对象作为参数传递.那就是TDA.在Analysis对象的方法中,您只需访问“亲密的朋友”数据即可遵守LoD.

这也符合SRP,因为您的DataSet仍然只是一个DataSet,而您的Analysis对象是一个Analysis对象.

这里的关键是这些原则往往是“相对论”的.这意味着,从获取数据并希望执行分析的父对象的角度来看,您正在“告诉”分析对象来做某事.

TDA的目的是您的父代码不应该查询您的DataSet的状态,然后根据此做出决定.它应该将对象传递给其他对象,并让这些对象履行其职责,这可能包括将这些对象查询到其状态,但这是可以的,因为它是在其责任的上下文中.

进一步参考：

http://pragprog.com/articles/tell-dont-ask

编辑：

如果你想要一个更权威的来源,那么没有比Martin Fowler自己更好的(最终读到你会发现这个评论)

http://martinfowler.com/bliki/TellDontAsk.html

But personally,I don’t use tell-dont-ask. I do look to co-locate data and behavior,which often leads to similar results. One thing I find troubling about tell-dont-ask is that I’ve seen it encourage people to become GetterEradicators,seeking to get rid of all query methods. But there are times when objects collaborate effectively by providing information. A good example are objects that take input information and transform it to simplify their clients,such as using EmbeddedDocument. I’ve seen code get into convolutions of only telling where suitably responsible query methods would simplify matters 07003. For me,tell-don’t-ask is a stepping stone towards co-locating behavior and data,but I don’t find it a point worth highlighting