Говорите, не спрашивайте и единственная ответственность - делать что-то новое с данными в классе

Когда вы разрабатываете программное обеспечение, вы всегда должны балансировать между разными принципами, потому что многие из них противоречат друг другу. Например, принцип DRY (не повторяйся) часто противоречит принципу единой ответственности, особенно когда две вещи действуют одинаково, но не в точности одно и то же.

Часто вам приходится решать, какой принцип более важен, и делать упор на этом принципе над другим (хотя вы должны стараться придерживаться как можно большего числа). Часто принципы работают вместе, иногда они работают друг против друга.

В этом случае «Скажи, не спрашивай» работает с другими принципами, такими как Закон Деметры (который, несмотря на свое название, все еще принцип в отношении программного обеспечения, и его лучше описать как принцип наименьшего знания).

LoD сообщает нам, что метод объекта должен вызывать только другие методы.

• На себе
• Об объектах, переданных в него в качестве параметра
• Любые объекты, созданные / экземпляры с объектом, переданным параметром
• объекты направляют объекты компонентов
• Или глобальная переменная

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

Итак, если мы объединим «Скажи, не спрашивай» с LoD, тогда совершенно нормально передавать объекты другому объекту для «запроса». Это означает, что у вас есть объект анализа, которому вы «говорите» что-то делать, передавая объект DataSet в качестве параметра. Это придерживается TDA. Внутри метода объекта Analysis вы придерживаетесь LoD, обращаясь только к данным «близких друзей».

Это также соответствует SRP, поскольку ваш DataSet по-прежнему является просто DataSet, а ваш объект Analysis является объектом Analysis.

Ключевой вывод здесь состоит в том, что эти принципы часто являются «релятивистскими». Это означает, что с точки зрения родительского объекта, который получает данные и хочет выполнить анализ, вы «говорите» объекту анализа что-то сделать.

Цель TDA состоит в том, чтобы ваш родительский код не запрашивал ваш DataSet о его состоянии, а затем принимал решения на основе этого. Вместо этого он должен передавать объекты другим объектам и заставлять эти объекты выполнять свои обязанности, которые могут включать в себя запросы этих объектов на предмет их состояния, но это нормально, потому что это в контексте их ответственности.

Дополнительная ссылка здесь:

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

РЕДАКТИРОВАТЬ:

Если вам нужен более авторитетный источник, нет никого лучше, чем сам Мартин Фаулер (прочтите в конце, вы найдете этот комментарий)

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

Но лично я не использую «скажи, не спрашивай». Я стараюсь объединить данные и поведение, что часто приводит к схожим результатам. Одна вещь, которая меня беспокоит в отношении «скажи-не-спрашивай», - это то, что я видел, как он побуждает людей становиться GetterEradicators, стремясь избавиться от всех методов запросов. Но бывают случаи, когда объекты эффективно взаимодействуют, предоставляя информацию. Хорошим примером являются объекты, которые принимают входную информацию и преобразуют ее для упрощения работы своих клиентов, например с помощью EmbeddedDocument. Я видел, как код зацикливался, говоря только о том, где подходящие методы запроса упростят задачу 1. Для меня «скажи-не-спрашивай» - это ступенька к совмещению поведения и данных, но я не считаю, что это стоит особо выделять.

Я бы создал объект DataAnalyzer, в обязанности которого входило бы создание отчета на основе некоторого анализа входных данных.

interface DataAnalyzer {

    public function analyze($input);

    public function report();
}

Теперь у нас есть разные виды анализа, которые нам нужны.

class AnalyzerOne implements DataAnalyzer {
    //one way of analyzing and reporting
}

class AnalyzerTwo implements DataAnalyzer {
   //other way of analyzing and reporting
}

Я могу заставить свой объект DataSet заполнять анализатор некоторыми входными данными для анализа, а затем делегировать ему отчетность.

class DataSet {

    private $data;

    //... other methods

    public function report(DataAnalyzer $analyzer) {
        //prepare input for the analyzer from the current state
        $analyzer->analyze($input);
        return $analyzer->report();
    }

}

В итоге клиент будет выглядеть так

$dataSet = new DataSet();
//...

$firstReport = $dataSet->report(new AnalyzerOne());
$secondReport = $dataSet->report(new AnalyzerTwo());

Таким образом, каждый объект отвечает за отдельные задачи, dataSet занимается своим делом, а анализатор отвечает за отчеты. Однако мы говорим DataSet использовать анализатор для создания отчетов. Затем DataSet сообщает анализатору, какой тип ввода использовать, и возвращает отчет.

Конечно, это не единственный способ, но в целом с таким объемом информации я думаю, что это правильная идея.

Похоже, возможно, ViewModel - это то, что вы хотите. У вас есть Model (DataSet), который отвечает за поддержание состояния ваших данных и того, что они представляют. У вас есть View (Report), который отвечает за отображение различных фрагментов данных для пользователя, но вы хотите преобразовать DataSet в представление данных, подходящее для просмотра?

Вы можете инкапсулировать ответственность за подготовку DataSet к просмотру - например, DataSetViewModel. У него могут быть такие функции, как GetDataInReportFormat().

Я думаю, что главное изменение заключается в том, чтобы изменить ваше мышление и рассматривать подготовку данных для просмотра как отдельную обязанность.

Может быть, очень простое применение наследования может решить вашу проблему.

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

Основное преимущество здесь заключается в том, что дочерние классы наследуют набор данных, внутренние компоненты, поэтому они принадлежат к одному семейству и могут получить доступ к набору данных данных.

Могу привести пример кода. Но давайте сначала посмотрим, что здесь говорится в комментариях.