Tell-Don’t-Ask

[slayerhabr]

Мне кажется «роботы» лучше описали этот принцип: robots.thoughtbot.com/post/27572137956/tell-dont-ask

[GrigoryPerepechko]

Пока не видел ни одного места где бы он был лучше описан чем на прагпроге — pragprog.com/articles/tell-dont-ask
Там сразу LoD и CQS описаны как неотделимые понятия.

[mayorovp]

Я нахожу такой принцип полезным, но не в отношении простых объектов, а в отношении более сложных единиц. Если применять принцип «Tell Don't Ask» повсеместно, то у объектов окажется слишком много ответственностей.

Как правило, у меня есть объект-источник данных, несколько объектов — обработчиков, и, возможно, фасад, который все это скрывает.

[wisd]

Я не понимаю как вообще можно не использовать в ООП этот принцип.
Если его не использовать то вместо классов и объектов вы пользуетесь просто структурами данных.

[GrigoryPerepechko]

Я думаю его все используют, вопрос только в осознанности и в мере. Если осознанности не будет, то вы например не сможете принять решение о рефакторинге классов для того чтобы применить его, вы напишете как проще, и позже ощутите последствия. А осознавая принцип вы сможете понять что вместо
if condition do возможно придётся пересмотреть ответственности, пошевелить код слегка и сделать только do

[EvilsInterrupt]

Отхождения от этого принципа все-таки возможно. Когда появляется еще одна задача при которой нужно разработать новый код использующий тот же набор данных что и в коде существующего класса. Тогда нужно оценить объем этих данных и если их достаточно много, то логично вынести в некий storage чем писать у существующего множество getBlahBlahBlah(). Тогда-то и появляется Данные отдельно Алгоритмы отдельно, просто потому что сработал другой более важный принцип «Не повторяйся»

[alexanderzaytsev]

Все-таки, «говори, а не спрашивай»

[PsyHaSTe]

Скорее уж «требуй».

Но имхо переводить вообще не стоит, фразу из трех предложение освоит даже гугл, а тут дураков вроде не держат

[alexanderzaytsev]

Автор перевода, к сожалению, не осилил.

И не «требуй», а именно «говори».

[lexus1990]

В теории понятно что это за принцип. Но давайте рассмотрим на практике. У нас есть класс платеж, которому мы можем сказать - отменись. Кроме изменения собственного статуса отмена платежа должна создать еще один обьект - обьект отмены.

class Payment {

fun reverse()

}

И тогда получается что либо tell don't ask метод reverse должен возвращать что-то, нарушая Command Query Separation, либо сам payment и reversal должны уметь себя куда-то сохранять - то есть получать интерфейс репозитория, что нарушает Single Responsability Principle.

Как быть с этим?

[malferov]

Когда в следующий раз захотите съесть в кафе яичницу, попробуйте не заказывать ее напрямую у повара. Обратитесь к официанту ;-)

Он (Invoker) получит от вас (Client) команду (Command) и точно знает, кому (Receiver) ее доставить. Повар знает, как готовить яичницу, и сообщит официанту о готовности. А официант знает, кто заказал у него яичницу, и уже через 5 минут вы насладитесь блюдом :-)