В каких случая и зачем нужно использовать трейты ?

Question

[nepster-web]

Прочитал про новую штуку в php trait

Сделал первый пример

trait Helper 
{
    public function str($s) 
    {
        return strtoupper($s);
    }
}


class HelloWorld 
{
    use Helper;
    
    public function __construct()
    {
        echo $this->str('test');  
    }
}

$MyHelloWorld = new HelloWorld();

Работа понятна, вопрос чем отличается вышепоказанный пример, от

class Helper {
    public static function str($s) 
    {
        return strtoupper($s);
    }
}


class HelloWorld 
{
    public function __construct()
    {
        echo Helper::str(get_class($this));  
    }
}

$MyHelloWorld = new HelloWorld();

В чем разница и в каких случаях нужно использовать трейты ?

Answer 1

[KorsaR-ZN]

Они нужны для избавления от дублирования кода, ну или например для множественного наследования.

Грубый пример:
У вас есть много классов, которые что-то записывают в лог, из класса в класс, это один и тот же участок кода, к примеру Logger::write(str), вот этот участок кода можно вынести в трейт LoggerTrait c методом logWrite, и потом во всех классах использовать $this->logWrite(str).
Потом удобно будет эту функцию переопределить в каком-то конкретном файле, если скажем там нужна какая-то специфичная запись в лог.

При таком подходе вы всегда класс логгера можете заменить, просто отредактировав всего один файл трейта, а не 100500 классов.

Еще пример:
В трейт можно вынести функцию isAjaxPost, для проверки, что запрос в контроллер пришел ajax post, и подключать в нужные контроллеры.

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

Comments

[nepster-web]

подскажите пожалуйста, еще такой момент, можно ли использовать трейт в качестве моста между разными модулями ?

[Сергей Протько]

@nepster09 можете пояснить?

Так же дополню @KorsaR-ZN, трейты хороший инструмент для рефакторинга, избавления от лишних статических вызовов, зависимостей и т.д. Помогают развязать код при умелом использовании. Единственное в чем я не согласен - множественное наследование на трейтах лучше не пытаться делать. Это больше макросы нежели какой-то механизм наследования. По сути там где вы пишите use TraitName просто вставляется содержимое трейта.

[nepster-web]

@Fesor всмысле когда, например модуль Блог хочет написать личное сообщение пользователю (Тесная связь модуля Блог и модуля Сообщения).

Берем модуле блог делаем трейт, который знает про модуль сообщения и везде в модуле блог работает с трейтом.

[KorsaR-ZN]

@Fesor Не соглашусь насчет макроса и того, что код вставляется в место use TraitName, в PHP это реализовано, почти так же, как extend, за исключением приоритетов, кто кого перекрывает. ну и да одноименные функции из трейтов друг друга перекрыть не могут, будет ошибка, но есть механизм выбора.

Насчет множественного наследования, это было в качестве примера, множественное наследование вообще штука не очень хорошая, но при грамотном и острожном использование пойдет :)

[Сергей Протько]

@nepster09 нет, тут пожалуй лучше старые добрые сервисы. Вообще модуль "блог" не связан с "сообщениями", модуль пользователей - возможно, но сервисы будут лучше.

[KorsaR-ZN]

@nepster09 Но только если вы трейты будете использовать, как обертку над локатором, di, или чем-то подомным. Иначе я не совсем понимаю, как вы хотите наладить этот мост...

[nepster-web]

@KorsaR-ZN Ну например если реализовывать такую штуку:
- пользователь отписал 10 тем, получил новый ранг и получил личное сообщение с уведомлением, прокомментировал 10 постов получил личное сообщение и тп. Тоесть модуль блог шлет сообщения пользователю за проделанные действия. Вызывать модуль сообщений внутри модели блога как-то не правильно.

[KorsaR-ZN]

@nepster09 Сходу так прям не ответить, всего скорей это не удачное решение, т.к получаем связь блога и сообщений, с другой стороны если система не сложна, то вполне себе решение.

Если делать через трейты, я бы наверное сделал следующем образом, трейт отвечал бы за получение экземпляра конкретного модуля, ну через какой-нить контейнер зависимостей, подключал в него все зависимости т.д.

trait UserModuleTrait
{
protected function getUserModule() { // логика создания }
}

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

Но тут получается такая страшная штука, если условия отправления сообщений сменить с 10, на к примеру каждого 3 отправленное в субботу утром, то получается постоянно лезть в модель блога для исправления.

Всего скорей тут лучше сделать через эйвент по факту создания новой записи, это эйвент отлавливать и уже в обработчики реализовать всю логику по отправки сообщений. А сами связи на модуле получать через контейнер сервисов, ну так будет правильнее...

Хотя еще раз повторюсь, если проект не сложный, то первый вариант вполне себе рабочее решение :)

[nepster-web]

большое спасибо вроде все понял.

Answer 2

[Сергей Протько]

Трейты нужны для уменьшения дублирования кода. Причем выносить в них стоит только тупой код, который не имеет смысла покрывать тестами. Все что делает хоть что нибудь умное в трейте хранить не стоит.

Пример когда трейты хороши - паттерн композиция.

interface A {
    function foo();
}

interface B {
    function bar();
}

trait AImpl {
    function foo() {
        return $this->a->foo();
    }
}

trait BImpl {
    function bar() {
        return $this->b->bar();
    }
}

class AB implements A, B {
    private $a;
    private $b;

    use AImpl;
    use BImpl;

    public function __construct(A $a, B $b) {
        $this->a = $a;
        $this->b = $b;
    }
}

Comments

[nepster-web]

А всеже чем отличается трейт от обычного подключения стороннего объекта ?

[nepster-web]

В композиции, я могу без проблем собрать обычные классы под общим итерфейсом. В чем будет разница ?

[Deerenaros]

@nepster09 может быть тем, что Вы не подключаете сторонний объект, а вызываете статичную функцию? Соль в том, что трейты позволяет выносить однотипную реализацию методов (не функций) и потом в любых дозах их миксить. Довольно удобная штука, но совершенно не обязательная.

[Сергей Протько]

@nepster09 это просто синтаксический сахар, упрощение. Как вы можете заметить, наша реализация класса, реализующая два интерфейса, вообще не содержит реализации методов интерфейсов. Вместо этого у нас есть трейт, проксирующий вызовы методов в интанс нужного инетфейса. Смысл в этом только тогда, когда трейт предоставляется разработчиком библиотеки, предоставляющей интерфейс.

Скажем в Silex трейтами импортируют функции в класс приложения без необходимости расширять класс. В трейтах же идет просто вызов методов из компонентов, взятых в контейнере. Можно обойтись и без этого, просто использовать компоненты на прямую, но чуть чуть код становится приятнее.

Я лично трейты не особо часто использую. Их можно использовать в контроллерах например для того что бы не загонять какие-то общие вещи, уменьшающие количество кода в базовый класс.