我一直在读很多关于TDA以及getter和setter方法的优点和缺点,虽然我不一定同意我读过的所有内容,假设你应该总是告诉而不是问,并且你应该避免访问者只要有可能,方法是否意味着所有方法都应该返回无效以符合这些准则/理想？
我理解现实并非所有方法都应该返回void,但我只是想完全理解这种看待OOP的方式.我似乎无法在其他任何地方找到解释.
"告诉,不要问",这本身就是一个愚蠢的过于概括的规则,而不是理想的规则.
在理想的是,一个对象有一个工作,它的整个工作,它的类是你把代码,做这项工作的地方.
但是,许多开发人员认为这个问题会使他们妥协这个理想......
假设您正在与很多其他人共享的大型代码库中工作,并且您得到了特殊要求:在您的特定用例中,您需要对象X以不同的方式完成其工作.在某些方面,最安全的方法是将特殊情况的代码分开.这通常意味着您必须检测您的特殊情况,查询X的状态,以便您可以在特殊情况下决定您希望它做什么,然后告诉X执行此操作.
不幸的是,当你这样做时通常会发生的事情是,你让你的特殊案例代码成为X工作的一部分.它正在查看有关X没有业务关注的内部信息,并使用它来做出没有业务的决策.现在没有一个地方可以找到执行X工作的代码,即使你的小改变是安全的,但每个人都很难弄清楚X的工作是如何完成的.
所以,不要这样做."告诉,不要问"的"请勿询问"部分意味着停止询问您没有业务可见的内部信息,并做出真正X工作的决定.
另一种方法是告诉.在X中添加一个方法或某些东西,让你说"我现在需要你以不同的方式工作".尽管如此,尽量不要完全不考虑你的特殊要求.然后,当您的特殊情况出现时,您只需告诉X它需要了解的内容,并将涉及X内部状态的决策留给X.