Комментарии 14
ну… сомнительно на самом деле… Я трейты применяю в контроллерах, выношу в них штуки, которые просто сокращают объемы кода. Например сериализация jmsSerializer-ом, валидация и проверка на ошибки, и т.д. Просто уменьшаю количество дублирования кода без необходимости выносить всю эту радость в базовый класс. А использовать трейты для того, что бы не писать геттеры/сеттеры и пару тройку аннотаций, это все же как по мне не очень. Нельзя зайти сходу в класс и увидеть что есть что и как это все в базе хранится (если с точки зрения разработчика, впервые видящего проект).
Это нужно в трейты лезть что бы аннотации посмотреть… А если там нужно не только аннотации для Doctrine, но еще и ассерты валидатора расставить (description, price, name), настроить сериализацию по группам и т.д. И уже придется от трейтов либо отказываться, либо дописывать. Причем если у нас две сущьности используют одно и то же поле, например description, и у нас по логике они должны учавствовать в сериализации объекта, но для разных групп, уже плохо выходит.
Это мое субъективное мнение, вы можете быть с ним не согласны.
Это нужно в трейты лезть что бы аннотации посмотреть… А если там нужно не только аннотации для Doctrine, но еще и ассерты валидатора расставить (description, price, name), настроить сериализацию по группам и т.д. И уже придется от трейтов либо отказываться, либо дописывать. Причем если у нас две сущьности используют одно и то же поле, например description, и у нас по логике они должны учавствовать в сериализации объекта, но для разных групп, уже плохо выходит.
Это мое субъективное мнение, вы можете быть с ним не согласны.
В принципе критика обоснованна. В php невозможно переопределить свойство из трейта и соответственно phpdoc для него.
Но этот пост и либа — скорее призыв к тому, чтобы в проектах таки выделять некоторые куски кода в трейты, потому что это реально удобно, особенно для связных сущностей.
Но этот пост и либа — скорее призыв к тому, чтобы в проектах таки выделять некоторые куски кода в трейты, потому что это реально удобно, особенно для связных сущностей.
Я согласен с тем что трейты можно и нужно использовать для устранения дублирования кода, но немного не согласен с тем, где. Скажем в контроллерах полно мест, где нужны всякие упрощалки, аля функции render или redirect. Скажем, у меня все это вынесено в трейты, которые подключаются там, где это нужно. Более того, можно сеттеры сервисов добавить, нужные только для этого трейта и т.д. А вот выносить в трейт геттеры/сеттеры полей сущностей я считаю плохой затеей. Мало ли, что потом придется делать с ними. Хотя опять же, может быть кейсы когда это оправдано и есть.
То есть если код хоть сколько нибудь относится к нашим доменным моделям, или же бизнес логике, то тут лучше трейты не использовать. А если это какой-то сервисный код, который приходится раз от раза переписывать, который делает что-то вроде «достать сервис, подготовить данные, задать какие-то общие настройки и т.д и выполнить метод», то тут определенно да, стоит вынести в трейт.
То есть если код хоть сколько нибудь относится к нашим доменным моделям, или же бизнес логике, то тут лучше трейты не использовать. А если это какой-то сервисный код, который приходится раз от раза переписывать, который делает что-то вроде «достать сервис, подготовить данные, задать какие-то общие настройки и т.д и выполнить метод», то тут определенно да, стоит вынести в трейт.
Ну вот у меня Column\Name постоянно дублировалось абсолютно одно и то же. Ради избавления от таких дублей — я готов валидацию в yml запихнуть, если честно.
Как раз логика и теряется во всех этих геттерах/эддерах/ремуверах/сеттерах. Например пользователь хочет указать ссылки на соц-сети. Это либо в массиве хранить, что не правильно, либо в разных полях. Можно запросто их вынести в какой ни будь
Как раз логика и теряется во всех этих геттерах/эддерах/ремуверах/сеттерах. Например пользователь хочет указать ссылки на соц-сети. Это либо в массиве хранить, что не правильно, либо в разных полях. Можно запросто их вынести в какой ни будь
Socialable и забыть. Понятно, что не везде так, к сожалению, можно
// Так почему бы это не вынести в трейты?
А производительность вы замеряли для сравнения?
А производительность вы замеряли для сравнения?
А что там будет с производительностью, позвольте спросить? Мне кажется что при наличии opcache разница будет в пределах погрешности.
yadi.sk/d/OkF0-1jeLB4TG
Вот картинка дифа без и с трейтом.
Ясно что на одном классе идет оверхед, из-за биндинга, но если классов, использующих трейт больше — трейты уменьшают кол-во опкода пропорционально величине методов.
Вот картинка дифа без и с трейтом.
Ясно что на одном классе идет оверхед, из-за биндинга, но если классов, использующих трейт больше — трейты уменьшают кол-во опкода пропорционально величине методов.
Трейты существуют для реалазиции интерфейсов которые имплементирует класс, тогда и все становится на свои места
github.com/zendframework/zf2/blob/master/library/Zend/EventManager/EventManagerAwareInterface.php
github.com/zendframework/zf2/blob/master/library/Zend/EventManager/EventManagerAwareTrait.php
тогда пример из статьи будет выглядеть
github.com/zendframework/zf2/blob/master/library/Zend/EventManager/EventManagerAwareInterface.php
github.com/zendframework/zf2/blob/master/library/Zend/EventManager/EventManagerAwareTrait.php
тогда пример из статьи будет выглядеть
class Book implements Column\IdInterface, Column\NameInterface, Column\PriceInterface, Column\DescriptionInterface, Column\CreatedDateInterface
{
use Column\Id;
use Column\Name;
use Column\Price;
use Column\Description;
use Column\CreatedDate;
}
А на мой взгляд это не так. Трейт — это возможность вынести повторяющийся функционал из класса, то что как-то изменяет класс. Например самый популярный пример трейта — синглтон
Тоесть статическая реализация метода
getIntance интерфейса SingletonInterface. Там где вы думаете что неплохо бы использовать trait и если это не предполагает интерфейса, в 99% случаев предпочтительнее использовать делегирование.class RssReaderService
{
public function setHttpClient(HttpClient $client) {}
public function getHttpClient() {}
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем трейты с пользой