Эффекты цепочки методов

Я знаю преимущества цепочки в PHP, но позволяет сказать, что у нас есть следующая ситуация

$Mail = new MailClass("mail") ->SetFrom("X") ->SetTo("X") ->SetSubject("X") ->AddRecipient("X") ->AddRecipient("X") ->AddRecipient("X") ->AddRecipient("X") ->AddRecipient("X") ->AddRecipient("X") ->Send();

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

Также хорошо читайте об этом, если ваш новый для Fluent-Interface: Martin Fowler на Fluent-Interfaces

Я полностью понимаю, что он не должен быть запрограммирован таким образом и может быть обработан следующим образом:

 $Mail = new MailClass("mail"); $Mail->AddRecipien( array(/*.....*/) ); $Mail->SetFrom("X"); $Mail->SetTo("X"); $Mail->SetSubject("X"); $Mail->Send();

но позволяет сказать, что у меня есть такой объект:

 $Order = new Order() ->With(22,'TAL') ->With(38,'HPK')->Skippable() ->With(2,'LGV') ->Priority();

Обратите внимание: ->With(38,'HPK')->Skippable() , это прекрасный пример Pro для этого типа программирования

Solutions Collecting From Web of "Эффекты цепочки методов"

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

Вы не можете напрямую связываться с экземпляром класса:

 $Mail = new MailClass("mail") ->SetFrom("X") ->SetTo("Y");

вы должны сначала создать экземпляр, а затем создать цепочку против объекта-объекта:

 $Mail = new MailClass("mail") ; $Mail->SetFrom("X") ->SetTo("Y");

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

Неустранимая ошибка: вызов функции-члена SetSubject () для не-объекта в C: \ xampp \ htdocs \ oChainTest.php в строке 23

если вы делаете исключения, вы можете обернуть цепочку в try … catch

 $Mail = new MailClass("mail"); try { $Mail->SetFrom("X") ->SetTo("Y") ->SetSubject("Z"); } catch (Exception $e) { echo $e->getMessage(); }

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

EDIT: Обновленный ответ для ответа на вопрос
addRecipient() функций медленнее, чем циклов, т. addRecipient() например, метод addRecipient() снижает производительность на addRecipient() бит по сравнению с вызовом addRecipients() который принимает массив, который затем обрабатывается в цикле.

Кроме того, для более сложной привязки методов к белым API-интерфейсам может потребоваться дополнительное ведение бухгалтерского учета данных, связанных с последним вызываемым методом, чтобы следующий вызов мог продолжить работу над этими данными, поскольку все методы возвращают тот же объект, на котором построена цепочка. Давайте посмотрим на ваш пример:

 ... ->With(22, 'TAL') ->With(38, 'HPK')->Skippable() ->With(2, 'LGV') ...

Это требует, чтобы вы помнили, что Skippable() должен применяться к (38, 'HPK') а не (22, 'TAL') .

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

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

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

Ответ на исходный вопрос:

[…] Проблемы с цепочкой – это тот факт, что вы не можете выполнять дополнительную проверку […]

В качестве альтернативы, реализуйте специальный метод проверки, который вы вызываете после установки всех свойств, и возвращаете вам массив отказов проверки (которые могут быть простыми строками или объектами, например, с именем ValidationFailure ).

Это обоюдоострый меч.

Хорошая сторона? Это чище, чем повторное обращение к классу, и хотя в основном это просто синтаксическое изменение, оно немного ускорит обработку. Было бы предпочтительнее зацикливать этот тип цепочки, чем цикл каждого вызова в longform.

Плохая сторона? Это вызовет проблемы с безопасностью, когда люди впервые привыкнут к ней. Будьте усердны в своем очищении от входящих в вас уроков, поэтому вы не пропускаете что-то там, вы не должны. Не слишком усложняйте свои занятия.

Предварительно проверьте свою информацию.
Предварительно авторизируйте своих пользователей.

Я не вижу проблем с привязкой этих методов в цикл, по производительности.