> Какие минусы наследования (PHP)

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

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

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

Наследование - это отношение "is-a", которое предполагает, что подкласс полностью повторяет поведение родителя. На практике это приводит к нескольким системным проблемам:

• Хрупкость базового класса: изменение родителя может незаметно сломать всех наследников. Особенно опасно, когда наследники переопределяют методы и полагаются на внутреннее состояние родителя.
• Нарушение инкапсуляции: подкласс получает доступ к protected-свойствам и методам, что связывает его с внутренней реализацией. Любая реорганизация родителя требует проверки всех наследников.
• Проблема ромба: в языках с множественным наследованием возникает неоднозначность. PHP обходит это через трейты, но трейты не решают проблему семантической связанности.
• Ограниченность моделирования: реальные отношения между объектами редко бывают строго иерархическими. Например, класс Bird с методом fly() заставляет пингвина либо наследовать ненужный метод, либо переопределять его с исключением.
• Сложность тестирования: чтобы протестировать подкласс, нужно создать и поддерживать корректное состояние родителя. Мокать родителя нельзя, так как наследование - это статическая связь.
• Невозможность изменения поведения на лету: тип связи фиксируется на этапе компиляции, нельзя подменить родителя в рантайме.

На практике

В реальных PHP-проектах наследование чаще всего оправдано для абстрактных классов с общей логикой (например, базовые репозитории или обработчики очередей). Но для доменной логики предпочтительнее композиция: класс хранит зависимости как свойства и делегирует им вызовы. Это даёт возможность подменять зависимости через интерфейсы, что улучшает тестируемость и гибкость.

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

Пример кода

PHP
// Плохо: наследование ради переиспользования
class FileLogger {
    protected function format(string $message): string {
        return date('Y-m-d H:i:s') . ' ' . $message;
    }
    
    public function log(string $message): void {
        file_put_contents('app.log', $this->format($message) . PHP_EOL, FILE_APPEND);
    }
}

class EmailLogger extends FileLogger {
    public function log(string $message): void {
        // Наследник зависит от format() родителя, но это не очевидно
        $formatted = $this->format($message);
        mail('admin@example.com', 'Log', $formatted);
    }
}

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

final class FileLogger implements LoggerInterface {
    public function __construct(private FormatterInterface $formatter) {}
    
    public function log(string $message): void {
        file_put_contents('app.log', $this->formatter->format($message) . PHP_EOL, FILE_APPEND);
    }
}

final class EmailLogger implements LoggerInterface {
    public function __construct(
        private FormatterInterface $formatter,
        private string $recipient
    ) {}
    
    public function log(string $message): void {
        mail($this->recipient, 'Log', $this->formatter->format($message));
    }
}

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

Начните с ключевой проблемы - жёсткой связанности и нарушения инкапсуляции. Затем приведите конкретный пример из практики, где наследование создало проблемы: например, изменение родительского метода сломало несколько подклассов. Обязательно упомяните принцип подстановки Лисков и покажите, как композиция решает те же задачи. Если спросят про PHP - отметьте отсутствие множественного наследования и ограничения трейтов. Хорошо, если вы сможете предложить альтернативу: интерфейсы + композиция + внедрение зависимостей.

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

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

• понимание разницы между наследованием и композицией;
• знание принципов SOLID, особенно LSP и ISP;
• умение видеть долгосрочные последствия архитектурных решений;
• способность привести реальный пример из практики;
• понимание особенностей PHP (трейты, отсутствие множественного наследования).

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

• Ответ "наследование - это зло" без объяснения, когда оно оправдано.
• Упоминание только проблемы ромба, которая в PHP неактуальна.
• Отсутствие примера нарушения LSP.
• Предложение использовать интерфейсы "везде", без понимания, что интерфейсы не решают проблему переиспользования кода.
• Игнорирование вопроса тестируемости и связанности с конкретной реализацией.