Я видел много раз Zend Framework, используя return $this; стиль рисунка – и с моей точки зрения:
Pro: кажется, это довольно неплохой стиль шаблона для объединения многих действий на одном и том же объекте и сокращения вашего кода.
Con: код выглядит немного странным, когда вы видите, что объект возвращает себя в методе, что делает что-то еще (например, setter для некоторого свойства)
Действительно ли это хорошая практика шаблонов или, может быть, практика анти- шаблонов ?
EDIT: хорошо было слишком много от моей стороны, чтобы назвать это «шаблон», спасибо всем за то, что указали мне на правильное направление!
Возвращаясь, вы можете подключать вызовы и устанавливать значения. Это очень полезно для настройки некоторого объекта (см. Интерфейс Fluent ). Вы можете очень легко выразить то, что хотите (и вы можете использовать разные типы возвращаемых данных для достижения желаемого).
Я обнаружил, что метод цепочки полезен в обстоятельствах, когда это имеет смысл; язык, специфичный для домена, например:
$query->select('*')->from('users')->where(array('user_id' => 1, 'verified' => 1));
Дело в том, что эти методы только возвращали бы void любом случае, и поэтому return $this просто функционирует как короткая ручная версия письма:
$query->select('*'); $query->from('users'); $query->where(...);
Мы все еще будем вызывать метод toSQL() или execute() чтобы использовать данные, с которыми мы заполнили наш объект.
По-моему, это не анти-шаблон и может функционировать как законный, разумный метод популяции объектов в правильных условиях.
Если вы имеете в виду «хорошую практику или плохую практику», вот мой вопрос:
С положительной стороны вы получаете синтаксический сахар.
С нижней стороны вы отказываетесь от значимых возвращаемых значений в пользу цепочки. Это не реально, потому что в конечном итоге вам придется иметь методы, которые возвращают что-то другое, кроме базового объекта, поэтому вы получаете некоторые методы, которые являются цепными, а некоторые из которых не являются (пользователи ваших классов получают удовольствие, угадывая, какие из них который.)
Или вы идете полным свиньи и делаете все из них целыми, независимо от того, что, но тогда вы оказываетесь в нелепых ситуациях, таких как возвращение поддельного «пустого» объекта ради сохранения цепи, какой предмет должен быть проверен на некоторое неявное свойство определить, является ли это «реальной» или просто ссылкой в цепочке.
Классическим примером является jQuery, в котором проявляются все симптомы: базовый объект пытается стать единственной базовой единицей данных во всем коде (все возвращает объект jQuery); проверка поддельного объекта ( if (obj.length) ); плюс самопротиворечие, когда ему еще нужно разбить цепочку на методы, такие как getAttribute() которые возвращают строку.
ИМХО, ужасно бесполезно делать вещи только ради этого синтаксического сахара.
Это не исключительно PHP / Zend Framework, так как есть много других языков программирования, которые используют свободный интерфейс. Я, конечно, думаю, что это пригодится и что использование свободного интерфейса – хороший способ кодирования. Хотя иногда коды выглядят странно, это не значит, что это неправильно, и я не думаю, что вы можете поместить это под con, чтобы быть честным.
В конце концов, программист видит, что он возвращает тот же объект, а не как он выглядит внутри кода свободного интерфейса. Я думаю, что самым большим профессионалом в свободном интерфейсе является читаемость кода. Если вы хотите услышать консоль, тогда отладка свободной сети – одна.
Это называется Fluent Interface, я не думаю, что это шаблон, но лучший способ реализовать функцию, чтобы уменьшить количество кода и улучшить читаемость.
Я позволю вам прочитать страницу Википедии: http://en.wikipedia.org/wiki/Fluent_interface