Используем трейты с пользой

[@Fesor]

ну… сомнительно на самом деле… Я трейты применяю в контроллерах, выношу в них штуки, которые просто сокращают объемы кода. Например сериализация jmsSerializer-ом, валидация и проверка на ошибки, и т.д. Просто уменьшаю количество дублирования кода без необходимости выносить всю эту радость в базовый класс. А использовать трейты для того, что бы не писать геттеры/сеттеры и пару тройку аннотаций, это все же как по мне не очень. Нельзя зайти сходу в класс и увидеть что есть что и как это все в базе хранится (если с точки зрения разработчика, впервые видящего проект).

Это нужно в трейты лезть что бы аннотации посмотреть… А если там нужно не только аннотации для Doctrine, но еще и ассерты валидатора расставить (description, price, name), настроить сериализацию по группам и т.д. И уже придется от трейтов либо отказываться, либо дописывать. Причем если у нас две сущьности используют одно и то же поле, например description, и у нас по логике они должны учавствовать в сериализации объекта, но для разных групп, уже плохо выходит.

Это мое субъективное мнение, вы можете быть с ним не согласны.

[@hell0w0rd]

В принципе критика обоснованна. В php невозможно переопределить свойство из трейта и соответственно phpdoc для него.
Но этот пост и либа — скорее призыв к тому, чтобы в проектах таки выделять некоторые куски кода в трейты, потому что это реально удобно, особенно для связных сущностей.

[@Fesor]

Я согласен с тем что трейты можно и нужно использовать для устранения дублирования кода, но немного не согласен с тем, где. Скажем в контроллерах полно мест, где нужны всякие упрощалки, аля функции render или redirect. Скажем, у меня все это вынесено в трейты, которые подключаются там, где это нужно. Более того, можно сеттеры сервисов добавить, нужные только для этого трейта и т.д. А вот выносить в трейт геттеры/сеттеры полей сущностей я считаю плохой затеей. Мало ли, что потом придется делать с ними. Хотя опять же, может быть кейсы когда это оправдано и есть.

То есть если код хоть сколько нибудь относится к нашим доменным моделям, или же бизнес логике, то тут лучше трейты не использовать. А если это какой-то сервисный код, который приходится раз от раза переписывать, который делает что-то вроде «достать сервис, подготовить данные, задать какие-то общие настройки и т.д и выполнить метод», то тут определенно да, стоит вынести в трейт.

[@hell0w0rd]

Ну вот у меня Column\Name постоянно дублировалось абсолютно одно и то же. Ради избавления от таких дублей — я готов валидацию в yml запихнуть, если честно.
Как раз логика и теряется во всех этих геттерах/эддерах/ремуверах/сеттерах. Например пользователь хочет указать ссылки на соц-сети. Это либо в массиве хранить, что не правильно, либо в разных полях. Можно запросто их вынести в какой ни будь Socialable и забыть. Понятно, что не везде так, к сожалению, можно

[@f3ath]

Скажите, кроме Вас с этим кодом еще кто-то работает?

[@hell0w0rd]

да, а что?

[@13i]

// Так почему бы это не вынести в трейты?
А производительность вы замеряли для сравнения?

[@Fesor]

А что там будет с производительностью, позвольте спросить? Мне кажется что при наличии opcache разница будет в пределах погрешности.

[@hell0w0rd]

yadi.sk/d/OkF0-1jeLB4TG
Вот картинка дифа без и с трейтом.
Ясно что на одном классе идет оверхед, из-за биндинга, но если классов, использующих трейт больше — трейты уменьшают кол-во опкода пропорционально величине методов.

[@necromant2005]

Трейты существуют для реалазиции интерфейсов которые имплементирует класс, тогда и все становится на свои места
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;
}

[@hell0w0rd]

А на мой взгляд это не так. Трейт — это возможность вынести повторяющийся функционал из класса, то что как-то изменяет класс. Например самый популярный пример трейта — синглтон

[@necromant2005]

Тоесть статическая реализация метода getIntance интерфейса SingletonInterface. Там где вы думаете что неплохо бы использовать trait и если это не предполагает интерфейса, в 99% случаев предпочтительнее использовать делегирование.

class RssReaderService
{
      public function setHttpClient(HttpClient $client) {}
      public function getHttpClient() {}
}

[@hell0w0rd]

Вы статью прочли? Я использую трейты для скаляров, в основном. Как к этому вообще относятся сервисы?

[@Fesor]

Вы чуть выше про трейты для реализации singelton предложили. К статье отношения это не имеет. Трейты для сервисов использовать вообще не стоит.