Комментарии 20
А расскажите, за что трейты так не любят? Использовал один раз в жизни и давно, но тогда пригодились..
По факту это сокрытие проблемы с copy-paste. Выглядит более-менее, а в действительности всё может быть плохо.
Еще с помощью трейтов можно инжектить часто используемые зависимости в через сеттер. Это уже больше похоже на черную магию, но сколько лишнего кода с ее помощью можно убрать. :)
Плохо, когда трейты используются как альтернатива сервисам. Это усложняет понимание кода.
Трейты очень легко использовать во вред, когда вместо качественной декомпозиции, вырывают куски кода в своеобразный include (чем трейт в некоторой степени и является). К тому же трейты и интерфейсы, имхо, это костыль вместо полноценного множественного наследования, в которое PHP не смог, к сожалению.
Это, наверное, комментарий о том, что любят за то, что так не должно быть.
Есть система с главным объектом, в котором вся работа, и под-объектом, в котором много более специфичной работы. Оказалось, что третий объект, доступный в главном объекте, нужен также и в том под-объекте. Под-объект создаётся ещё в конструкторе главного объекта, с помощью красивой магии контейнера Symfony Dependency Injection. Согрешил душой, и вместо того, чтобы перехреначить это всё, вынес третий объект в трэйт для главного и для под-объекта и сделал его синглтоном. За этот хак до сих пор ужасно стыдно, но профит был просто шикарный. Дело в том, что с точки зрения DDD было логично, чтобы тот трэйтнутый объект был доступен везде, где можно, так что на сопровождаемость системы эффект хака был нулевой. В общем, хоть я и люблю Perl, но PHP тоже хорош, есть где развернуться при необходимости. Анонимные классы тоже, кстати, весьма хороши! :)
Ни разу не было необходимости в анонимных классах. Зачем они могут понадобиться, например?
Это, наверное, не столько вопрос необходимости, сколько локального удобства. Был случай, когда был нужен просто безымянный объект для передачи по SOAP. Были свойства, которые в этом объекте нужны всегда, а были такие, которые нужно добавлять по условию, условий несколько. Я пошёл таким путём: в месте перед формированием и отправкой сообщения проверяются условия, создаётся ветвление, в каждой ветке которого инициализируется анонимный класс, который использует базовый трэйт (свойства, которые нужны всегда) и трэйты с условными свойствами. В результате, с одной стороны, SOAP API всегда получал кошерный объект, имеющий только необходимые свойства, а с другой — логика производства значений этих свойств была инкапсулирована под говорящими именами трэйтов с удобствами конструктора, приватных методов и поддержкой IDE. Можно, наверное, было сделать и по-другому, но, как обычно, всё должно быть готово ещё вчера, времени на глубокие размышления нет. Впрочем, поддерживать и расширять эту конструкцию было вполне удобно.
Капчей отсеиваются все «недостойные»? :)
UPD: При вводе существующего email форма просто перезагружается, без отображения ошибки.
В общем, провели вам тестирование с коллегами, пока пытались зарегистрироваться :)
Встречаем PHP 8 вместе: советы по обновлению, мнения за и против и интервью с ключевыми разработчиками