Наследование и полиморфизм

1. Прототипное наследование в JavaScript: скрытые риски инициализации

Многие разработчики полагают, что прототипное наследование — это просто цепочка объектов. Однако нюанс кроется в коварном поведении при инициализации свойств ссылочного типа. Если вы определите массив в прототипе, все экземпляры будут иметь доступ к одному и тому же массиву. Изменение в одном экземпляре — и данные «утекают» в другой. Профессионалы всегда инициализируют массивы и объекты внутри конструктора, а не в прототипе. Это гарантирует, что каждый экземпляр получит собственную копию, а полиморфные методы останутся общими для экономии памяти.

• Ошибка: размещение this.items = [] в прототипе — все экземпляры получают ссылку на один массив.
• Правильно: в конструкторе this.items = [] — каждому экземпляру новый массив.
• Полиморфизм: методы (например, getPrice()) остаются в прототипе, экономя память и позволяя переопределять поведение через super.
• Инструмент: используйте Object.create() для явного задания прототипа без лишних конструкций.
• Совет: при наследовании от класса, содержащего ссылочные свойства, всегда вызывайте родительский конструктор через Parent.call(this).

2. Классическое наследование в PHP: переопределение vs сокрытие методов

В PHP многие путают переопределение (override) с сокрытием (hiding). Переопределение меняет поведение полиморфного метода, а сокрытие просто вводит новый статический метод с тем же именем, что уничтожает полиморфизм. Коварство возникает, когда вы переопределяете метод без указания parent:: — вы теряете базовую логику. Ещё одна ловушка: если метод в родительском классе объявлен как final, полиморфное переопределение невозможно — это фиксирует архитектуру. Профессионалы всегда проверяют сигнатуры на соответствие LSP (Liskov Substitution Principle) и используют self:: только для статических методов, а для экземплярных — static:: для отложенного статического связывания.

• Кейс: метод calculateShipping() — всегда переопределяйте, если хотите разное поведение для дочерних классов.
• Подводный камень: parent::calculateShipping() в теле нового метода — обязателен, если нужно сохранить базовую логику.
• Полиморфизм: при объявлении интерфейса ShippingInterface все методы в нём — публичные, иначе полиморфизм сломается.
• Практика: используйте abstract class для шаблонов, а интерфейсы — для контрактов. Не смешивайте их без необходимости.
• Инструмент: PhpStorm подсвечивает сигнатуры, несовместимые с LSP — пользуйтесь статическим анализом.

3. Полиморфизм через интерфейсы: настоящая гибкость или оверинжиниринг?

Многие новички создают интерфейсы «на всякий случай», плодя пустые абстракции. Полиморфизм становится полезным только когда поведение различается в зависимости от контекста. Например, интерфейс LoggerInterface с методом log() — классический пример, когда полиморфизм оправдан: файловый логгер, логгер в БД, облачный логгер. Если же у вас один класс с одним поведением — интерфейсы избыточны. Профессионалы используют полиморфизм в точке внедрения зависимости, а не в месте вызова. То есть вы передаёте логгер в конструктор, а не создаёте его внутри метода. Это упрощает тестирование и замену.

• Признак оверинжиниринга: интерфейс имеет ровно одну реализацию без планов на расширение в ближайшие 6 месяцев.
• Правильный паттерн: интерфейс + несколько реализаций, где каждая реализация — отдельный класс с уникальной логикой.
• Пример: PaymentGatewayInterface с методами pay() и refund() — Stripe, PayPal, Square.
• Ловушка: если интерфейс содержит 10 методов, а реализация использует только 2 — скорее всего, вы нарушаете принцип разделения интерфейса (ISP).
• Техника: используйте instanceof только в крайнем случае — он убивает полиморфизм. Предпочитайте отдельные интерфейсы под разные обязанности.

4. Переопределение приватных методов: мифы правды

Распространённое заблуждение: приватные методы можно переопределять. На самом деле приватный метод не участвует в полиморфизме, так как он привязан к классу во время компиляции. В JavaScript приватные поля (#field) ведут себя аналогично — они доступны только внутри объявившего их класса. Если вы создадите дочерний класс и объявите метод с таким же именем, это будет новый метод, а не переопределение. Профессионалы, желая сделать метод доступным для переопределения, используют protected (в PHP) или _method (соглашение в JS). Ещё один нюанс: в TypeScript приватные поля (private) транслируются в JavaScript как обычные свойства, поэтому доступ к ним всё равно возможен через рефлексию — не стоит полагаться на них для безопасности.

• Правило: приватные методы — только для внутренней реализации, не ожидайте их переопределения.
• Ошибка: пытаться переопределить private function validate() в дочернем классе — это новый метод.
• Решение: используйте protected function validate(), если нужна возможность переопределить валидацию в подклассах.
• Специфика JS: приватные поля # — настоящие приватные, не наследуются.
• Рекомендация: для полиморфного поведения всегда используйте публичные или защищённые методы.

5. Рекомендации по выбору стратегии для веб-проекта

Если вы пишете небольшую библиотеку или утилиту — достаточно прототипного наследования в JS или простых классов в PHP без глубокой иерархии. Для средних и крупных проектов (Laravel, Symfony, React-приложения) критично использовать полиморфизм через интерфейсы и трейты. Избегайте наследования глубже 3 уровней — это верный знак архитектурной проблемы. Для критичных к производительности мест (например, циклы рендеринга) замените полиморфные вызовы на прямые — это даёт до 30% прироста скорости. Но делайте это только после профилирования.

• Выбор 1: для CRUD-приложений — композиция через интерфейсы, наследование только для моделей (Active Record).
• Выбор 2: для микросервисов — полиморфизм на уровне адаптеров (например, CacheInterface), не используйте глубокие иерархии.
• Выбор 3: для UI-компонентов (React/Vue) — используйте композицию, а не наследование. Полиморфизм достигается через пропсы и слоты.

Итоговая рекомендация: в 2026 году приоритет отдавайте композиции и интерфейсам, наследование оставляйте только для ситуаций, где это действительно даёт изоляцию общих данных (например, базовый класс для сущностей). Полиморфизм должен быть явным — через сигнатуры методов, а не через магию прототипов. Профилируйте код: если переопределение методов вызывает более 5% накладных расходов — замените на условные операторы или стратегии.

Добавлено: 23.04.2026