Трейты в PHP: когда полезны, а когда только мешают

Трейты появились в PHP 5.4 и с тех пор не менялись концептуально: это механизм горизонтального переиспользования кода. Класс наследует один родитель, но подмешать в него можно сколько угодно трейтов. Проблема в том, что трейт легко превращается в свалку методов, которую невозможно протестировать отдельно и тяжело отследить при чтении класса. Разберём, в каких задачах трейт даёт выигрыш перед наследованием и композицией, и чем именно вы платите, когда выбираете его.

Материал для PHP 8.x. Синтаксис use внутри класса и разрешение конфликтов через insteadof работают одинаково начиная с 5.4, но примеры используют типизированные свойства (PHP 7.4+) и промоушен конструктора там, где сравниваем с композицией.

Что делает трейт и чего не делает

Трейт — это набор методов и свойств, которые компилятор копирует в тело класса при подключении. Не наследование, не включение объекта — именно копирование на этапе компиляции. Отсюда следуют все свойства и все проблемы.

• Трейт нельзя инстанцировать. new MyTrait() — фатальная ошибка.
• Трейт может объявлять свойства, абстрактные методы, статические методы и константы (константы — с PHP 8.2).
• Метод класса переопределяет одноимённый метод из трейта. Метод трейта, в свою очередь, переопределяет унаследованный от родителя.
• Два трейта с одинаковым именем метода дают фатальную ошибку, пока конфликт не разрешён явно.

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

Где трейт действительно выигрывает

Одинаковое поведение в несвязанных классах

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

<?php
// PHP 8.x
trait Timestampable
{
    private ?\DateTimeImmutable $createdAt = null;
    private ?\DateTimeImmutable $updatedAt = null;

    public function touchCreated(): void
    {
        $this->createdAt = new \DateTimeImmutable();
    }

    public function touchUpdated(): void
    {
        $this->updatedAt = new \DateTimeImmutable();
    }

    public function getCreatedAt(): ?\DateTimeImmutable
    {
        return $this->createdAt;
    }
}

class Order
{
    use Timestampable;
    // своя логика заказа
}

class Comment
{
    use Timestampable;
    // своя логика комментария
}

Order и Comment не связаны наследованием, но оба получают одинаковую работу с датами без дублирования кода. Ровно тот случай, ради которого трейты вводили.

Добавление свойств, которые обязаны жить в самом объекте

Композиция через вложенный объект не может напрямую объявить protected-свойство в подключающем классе. Трейт — может. Если поведение требует, чтобы состояние физически лежало в целевом объекте (например, для сериализации через get_object_vars или для доступа из наследников), трейт делает это, а объект-помощник — нет.

Трейт — это не «интерфейс с реализацией по умолчанию». Это copy-paste, который выполняет компилятор вместо вас. Всё, что плохо в ручном копировании кода, остаётся плохим и здесь — просто становится незаметнее.

Где трейт мешает

Скрытые зависимости от целевого класса

Самая частая ошибка — трейт, который дёргает $this->property или $this->method(), не объявленные в самом трейте. Такой трейт молча компилируется, но падает в рантайме, если подключить его в класс без нужного свойства.

<?php
// Плохо: трейт полагается на $this->connection,
// но ниоткуда его не требует
trait Persistable
{
    public function save(): void
    {
        // упадёт, если в классе нет свойства connection
        $this->connection->persist($this);
    }
}

Способ обезопасить — объявить контракт через абстрактный метод в трейте. Тогда класс, забывший его реализовать, не скомпилируется.

<?php
trait Persistable
{
    // класс обязан предоставить соединение
    abstract protected function getConnection(): \PDO;

    public function save(): void
    {
        $connection = $this->getConnection();
        // работа с $connection
    }
}

Абстрактный метод в трейте — недооценённый приём. Он превращает неявную зависимость в явный контракт, проверяемый компилятором.

Конфликт имён и его разрешение

Если два трейта объявляют одноимённый метод, PHP не выберет за вас — будет фатальная ошибка. Разрешать нужно вручную через insteadof и, при желании, дать второму методу псевдоним через as.

<?php
trait FileLogger
{
    public function log(string $message): void { /* в файл */ }
}

trait DbLogger
{
    public function log(string $message): void { /* в базу */ }
}

class Service
{
    use FileLogger, DbLogger {
        FileLogger::log insteadof DbLogger; // основной — файловый
        DbLogger::log as logToDb;           // второй доступен как logToDb
    }
}

Работает, но это красный флаг: если два трейта конфликтуют, скорее всего они пересекаются по ответственности, и стоит подумать о композиции.

Трейт против наследования и композиции

Три механизма решают пересекающиеся задачи, но платите вы за них по-разному.

Когда что выбирать

• Трейт — поведение маленькое, без внешних зависимостей, нужно в несвязанных классах, и вам важен доступ к свойствам целевого объекта. Пример: работа с временными метками, простые геттеры для общего набора полей.
• Композиция — поведение содержит логику, которую хочется тестировать и подменять в тестах, или зависит от внешних сервисов (БД, HTTP-клиент, кеш). Вынесите в отдельный класс и внедрите через конструктор.
• Наследование — между классами есть настоящее отношение «является», и подтип полностью подставим вместо базового типа.

Практический критерий: если метод трейта обращается к внешнему сервису — это почти всегда сигнал, что нужна композиция, а не трейт. Трейт с зависимостью от PDO, HTTP-клиента или кеша невозможно протестировать в изоляции и невозможно замокать.

Что ломается на практике

• Статические свойства трейта. Каждый класс, подключивший трейт со статическим свойством, получает свою копию этого свойства. Общего состояния между классами не будет — частый сюрприз при попытке сделать счётчик или реестр через трейт.
• Порядок объявления в базе. Метод класса тихо переопределяет одноимённый метод трейта. Если вы добавили метод в трейт, а в классе давно лежит одноимённый, поведение не изменится — и никакой ошибки не будет.
• Разбухание. Трейт на 300 строк с десятком методов — это класс, который стыдливо назвали трейтом, чтобы избежать наследования. Такой трейт скрывает связность: методы делят приватные свойства, но formально их можно подключить куда угодно.

Что делать дальше

Пройдитесь по существующим трейтам в проекте с одним вопросом к каждому: обращается ли он к чему-то, что сам не объявляет. Если да — переведите зависимость в абстрактный метод трейта либо вынесите поведение в отдельный класс и внедряйте через конструктор. Для новых задач сначала прикиньте композицию, и только если она проигрывает по цене (нужен доступ к protected-свойствам, поведение без состояния и логики) — берите трейт. Тесты — лучший индикатор: если поведение хочется протестировать отдельно, а через трейт это невозможно, вы выбрали не тот инструмент.