Pull to refresh

Comments 11

Пока не видел ни одного места где бы он был лучше описан чем на прагпроге — pragprog.com/articles/tell-dont-ask
Там сразу LoD и CQS описаны как неотделимые понятия.
Я нахожу такой принцип полезным, но не в отношении простых объектов, а в отношении более сложных единиц. Если применять принцип «Tell Don't Ask» повсеместно, то у объектов окажется слишком много ответственностей.

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

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

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

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

class Payment {

fun reverse()

}

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

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

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

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

Sign up to leave a comment.

Articles