> Какие альтернативы наследованию существуют (PHP)

Короткий ответ

Основные альтернативы наследованию - композиция, делегирование, интерфейсы и трейты. Композиция подразумевает включение объектов вместо расширения классов, делегирование - передачу вызовов вложенному объекту. Интерфейсы задают контракт без реализации, трейты позволяют переиспользовать код без иерархии. В PHP также актуальны анонимные классы и замыкания для стратегий. Главный принцип - "предпочитай композицию наследованию" (composition over inheritance), так как она даёт гибкость и избегает проблем множественного наследования и хрупкой иерархии.

Подробное объяснение

Наследование - мощный, но жёсткий механизм: оно создаёт сильную связь между родителем и потомком, нарушает инкапсуляцию и приводит к проблеме "хрупкого базового класса". Альтернативы решают эти проблемы разными способами.

Композиция - класс содержит другие объекты и использует их поведение. Например, вместо class Dog extends Animal делаем class Dog { private $movement; }. Это позволяет менять поведение на лету и не создаёт жёсткой иерархии.

Делегирование - частный случай композиции, когда класс переадресует вызовы вложенному объекту. В PHP это часто реализуется через магический метод __call, но лучше явно прописывать методы-обёртки для читаемости.

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

Трейты - механизм горизонтального переиспользования кода в PHP. Позволяют включить методы в несколько классов без наследования. Но трейты не решают проблему состояния и могут создавать конфликты имён.

Стратегия и другие паттерны - вынос изменяемого поведения в отдельные классы и передача их через конструктор или сеттер. Это классический паттерн Strategy, который заменяет переопределение методов.

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

На практике

В реальном PHP-коде чаще всего комбинируют подходы. Например, в Laravel или Symfony репозитории обычно используют композицию с Query Builder, а не наследуются от базового репозитория. Сервисы строятся через dependency injection, где зависимости передаются в конструктор - это композиция.

Типичный пример: вместо создания BaseController с кучей методов, лучше вынести общую логику в отдельные классы (например, ResponseFormatter, Validator) и внедрять их в контроллеры.

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

При проектировании важно сначала определить контракты (интерфейсы), затем реализовать их через композицию, и только если действительно есть жёсткая иерархия "is-a" - использовать наследование.

Пример кода

PHP
<?php

// Плохо: наследование ради переиспользования
class FileLogger {
    public function log(string $message): void {
        // запись в файл
    }
}

class UserService extends FileLogger {
    public function createUser(array $data): void {
        $this->log('Creating user');
        // логика создания
    }
}

// Хорошо: композиция и интерфейс
interface LoggerInterface {
    public function log(string $message): void;
}

class FileLogger implements LoggerInterface {
    public function log(string $message): void {
        // запись в файл
    }
}

class UserService {
    public function __construct(private LoggerInterface $logger) {}
    
    public function createUser(array $data): void {
        $this->logger->log('Creating user');
        // логика создания
    }
}

// Делегирование через явные методы
class UserRepository {
    public function __construct(private DatabaseConnection $db) {}
    
    public function find(int $id): ?User {
        return $this->db->query('SELECT * FROM users WHERE id = ?', [$id]);
    }
}

Как отвечать на собеседовании

Начните с главного тезиса - "composition over inheritance". Затем перечислите основные альтернативы: композиция, делегирование, интерфейсы, трейты. Объясните, когда что выбирать: интерфейсы - для контрактов, композиция - для переиспользования поведения, трейты - для сквозной функциональности.

Приведите конкретный пример из практики, где наследование создало проблемы, и как вы решили это через композицию. Покажите понимание trade-off: композиция даёт гибкость, но требует больше кода и явной передачи зависимостей.

Упомяните, что в PHP нет множественного наследования, поэтому трейты и интерфейсы - единственные способы горизонтального расширения. Если спросят про паттерны - назовите Strategy, Decorator, Adapter как примеры замены наследования.

Что проверяет интервьюер

Интервьюер оценивает:

• понимание принципов ООП и их ограничений
• способность проектировать гибкие архитектуры
• знание специфики PHP (трейты, анонимные классы)
• умение обосновывать выбор подхода
• практический опыт - не просто теорию, а реальные кейсы

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

Типичные ошибки

• Отрицание наследования - говорить, что наследование всегда плохо. Это не так, оно полезно для стабильных иерархий.
• Путаница между композицией и агрегацией - композиция подразумевает жизненный цикл вложенного объекта, агрегация - нет.
• Злоупотребление трейтами - трейты не заменяют композицию, они лишь переиспользуют код, но не решают проблему состояния.
• Игнорирование интерфейсов - без интерфейсов композиция теряет смысл, так как нет контракта для замены зависимостей.
• Слишком глубокие иерархии - даже если используете наследование, не стройте больше 2-3 уровней.
• Отсутствие примеров - теория без практики выглядит неубедительно, всегда готовьте реальный кейс.