Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Статья актуальная, но примеров кода маловато, хотелось бы побольше примеров применения из жизни.
Мне вместо трейтов больше нравятся поведения, их и тестами покрывать легче и поведение объекта более предсказуемо.
Мне вместо трейтов больше нравятся поведения, их и тестами покрывать легче и поведение объекта более предсказуемо.
Мне вместо трейтов больше нравятся поведения
Я правильно понимаю что вы говорите это в контексте Yii? Если так, то тут есть очень большая разница, трэйты != миксины, а поведения в Yii имеют претензии на то что бы называться миксинами.
примеров кода маловато
Обычно это бойлерплейт и хелперы, которые и в базовый класс не вынесешь (не удобно), и в каждом классе писать не удобно. В своих проектах я использую трейты для расширения контроллеров (добавление методов-упрощалок, реализующих какую-то весьма тупую логику, которую не особо удобно покрывать юнит тестами), ну и пример с DomainEvent трейт такой же как и в статье. Более необходимости использовать трэйты я не вижу.
github.com/nkt/doctrine-columns — в тему. Трейты для популярных полей, при работе с ORM doctrine. Собственно либа демонстрирует подход, а не навязывает свое использование.
Статья о библиотеке на хабре
Статья о библиотеке на хабре
Это не оно же, только нативное? doctrine-orm.readthedocs.org/en/latest/tutorials/embeddables.html
Ужасная идея агитирующая делать анемичную модель. Если у вас есть типичные поля, лучше использовать объекты-значения.
Все же поясню, как и говорится в статье, сущности это не то место где стоит использовать трэйты. В этом репозитории трейты по сути нужны только для того, что бы не писать геттеры/сеттеры. Как по мне лучше пусть IDE сгенерирует это дело. А еще лучше — вообще отказаться от использования сеттеров.
Есть опыт использования подобных без-сеттерных сущностей в контексте sf2? И не создает ли это больше проблем чем решает?
В моем случае не создает вообще никаких проблем. Единственная проблема — необходимость использовать DTO (можно просто массивчики) и связанные с этим ограничения при работе с symfony/forms. Но я пишу апишки и там формы не нужны. Да и не сказал бы что это такой уж недостаток, он в принципе полезный. Ограничивает разработчика и явно отделяет данные запроса от данных модели, но на небольших проектах не удобно.
Обычно использовал трейты, как такой инструмент для избавления от копи-паста, пока «правильная архитектура» еще не созрела (или временно невозможна из-за необходимости большого рефакторинга).
P.S. Идея мириться со статическими методами, когда не нужно состояние, при возможности написать обычную функцию (за исключением порождающих паттернов), в очередной раз наталкивает меня на мысль, что PHP все больше начинает напоминать монструозную Java, где ни строки без класса не напишешь.
P.S. Идея мириться со статическими методами, когда не нужно состояние, при возможности написать обычную функцию (за исключением порождающих паттернов), в очередной раз наталкивает меня на мысль, что PHP все больше начинает напоминать монструозную Java, где ни строки без класса не напишешь.
Что-то я Вас не понял. А кто Вам не даёт писать простые ф-ции, вместо хелперов?
В том-то и дело, что язык не запрещает этого делать. В то же время, большинство кода, который мне попадался на глаза, использовал для этого статические методы.
Ну если Вы хотите писать подключение файлов с этими ф-циями, — пишите.
Это же делается, в больше степени, для того, чтобы не писать подключение файла, а положить это на плечи автолоудера (хотя в PHP еще можно переопределять и статические методы, но об это тсссссс...).
Это же делается, в больше степени, для того, чтобы не писать подключение файла, а положить это на плечи автолоудера (хотя в PHP еще можно переопределять и статические методы, но об это тсссссс...).
Ну справедливости ради, можно в composer.json все это прописать и тогда никаких проблем с автозагрузкой.
Если у меня будет 300 ф-ций и каждая будет лежать в отдельном файле (скажем не я писал этот код и он так реализован), Вы предлагаете ВСЕГДА подключать эти 300 файлов, даже если мне нужно будет только 16 ф-ций???
Да, почему бы и нет. opcache все положит в разделяемую память, обращения к файловой системе можно нивелировать (просто отключить у opcache инвалидацию кэша).
Ваше право, делайте как хотите :)
ну как минимум я не стану плодить 300 функций и уж тем более не буду ложить это в отдельные файлы. Обычно это пара файликов только с самым необходимым. В любом случае это лучше чем классы-утилиты.
Я не понимаю — чем лучше?
Тем что класс — это сущность, порождающая объекты, а не namespace для функций. А весь этот спор — как раз явный показатель того, что у языка с этим проблемы.
Не считаю, что этот ответ отвечает на вопрос «ЧЕМ лучше?».
Имхо, это как: «Гвозди можно забивать молотком, а можно пассатижами. Молоток придумали и спроектировали, чтобы забивать гвозди, а пассатижи — чтобы делать куда более сложные манипуляции. Вопрос — чем лучше забивать гвозди и почему?»
Знаете, что-то мне подсказывает, что Вы все-же сами пишете хелперы, а не набор ф-ций. Конечно я могу ошибаться, но думаю что многие в команде будут против подключать файлы с ф-циями руками, а прописывать это в композере — это и есть «забивать гвозди пассатижами».
Конечно, в итоге в обоих случаях приходится забивать гвозди пассатижами.
а прописывать это в композере — это и есть «забивать гвозди пассатижами».
Аргументируйте, что противоестественного в этом? Что вас в этом пугает? Руками ничего дергать не надо, по сути все та же автоматическая загрузка функций, просто не по требованию. Казалось бы должно бы медленнее работать, но нет, opcache нам в этом поможет. Мне серьезно интересно, возможно я каких-то проблем не вижу…
Что до вашего примера с 300-ми файлами, если это зависимости — бог с ним (хотя это нереально много и очень не реалистичный кейс). Если же речь идет о функциях-хелперах в составе вашего проекта, то тут возникает вопрос… а зачем вам столько и почему они каждый в отдельном файле?
Потому, что эти ф-ции являются частью проекта, а не подключаемым модулем. Поэтому я считаю их подключение не должно переноситься в настройку зависимостей (композер).
300 — да, Вы правы, пример сильно утрированный и высосанный из пальца, но все равно, я не вижу преимущества простой ф-ции над хелпером, который подключается автоматически и при большом желании поведение данного метода может быть переопределено.
300 — да, Вы правы, пример сильно утрированный и высосанный из пальца, но все равно, я не вижу преимущества простой ф-ции над хелпером, который подключается автоматически и при большом желании поведение данного метода может быть переопределено.
в настройку зависимостей (композер).
то есть, если следовать вашей логикой, вы пишите свои автолоадеры для классов вместо того что бы использовать генерируемый composer-ом?
может быть переопределено
Мне кажется это не правильно…
то есть, если следовать вашей логикой, вы пишите свои автолоадеры для классов вместо того что бы использовать генерируемый composer-ом?
Нет, использую автолоудер фреймворка. Если представить ситуацию, что его не хватает, то не писал бы
автолоадеры, а просто написал бы автолоадер (один), для всего что мне нужно.
Три причины:
— отсутствие нормальных автолоадеров для функций
— логическая принадлежность к классу: те же кастомные конструкторы и прочие фабричные методы
— исторически сложившаяся привычка, когда нэймспэйсов не было
— отсутствие нормальных автолоадеров для функций
— логическая принадлежность к классу: те же кастомные конструкторы и прочие фабричные методы
— исторически сложившаяся привычка, когда нэймспэйсов не было
90% использования трейтов в моём коде — дефолтная реализация поведенческих интерфейсов типа Observable
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я использую трейты