Коротко: наследование — это «is‑a» (B является A) и позволяет переопределять/расширять поведение базового класса; композиция — это «has‑a» (B содержит A) и реализуется через делегирование. Обычно предпочитают композицию, потому что она менее хрупкая и даёт большую гибкость; наследование оправдано, когда действительно требуется подтип с сохранением семантики и контрактов базового класса.
Пояснения и практические критерии
- Семантика:
- Наследование — когда логически верно: подкласс должен быть подстановочным значением суперкласса (Liskov Substitution Principle). Если объект B может везде заменять A без нарушения инвариантов/контрактов — наследуйте.
- Композиция — когда один объект содержит/использует другой, а не является им.
- Реюз и поведение:
- Наследование даёт повторное использование реализации и возможность переопределять методы (как в вашем примере: `class B extends A { void m() { super.m(); /*...*/ } }`).
- Композиция даёт делегирование и более явный контроль над интерфейсом и видимостью зависимостей: `class B { private A a; void m() { a.m(); /*...*/ } }`.
- Преимущества наследования:
- Удобно для расширения абстрактных классов/фреймворков.
- Лаконично, когда поведение и контракты полностью совпадают и базовый класс стабилен.
- Минусы наследования:
- Хрупкий базовый класс (fragile base class problem): изменение суперкласса может сломать подклассы.
- Сильная связность, сложнее рефакторить, ограничение одним родителем в Java.
- Нарушение инкапсуляции (доступ к protected) может создать зависимости на внутренние детали.
- Преимущества композиции:
- Слабая связность, легче тестировать и заменять зависимости.
- Позволяет комбинировать поведения (делегирование, стратегии) и менять реализации в рантайме.
- Избегает проблем наследования при изменениях базового класса.
- Минусы композиции:
- Немного больше шаблонного кода (методы-делегаты), но это часто компенсируется гибкостью.
Когда явно выбирать наследование:
- Б действительно является A по смыслу и должен удовлетворять всем контрактам A.
- Базовый класс задуман как расширяемый (абстрактный класс/публичный API), стабилен и документирует, какие методы можно переопределять.
- Нужно переопределить/переопределить поведение без явной делегации к внешнему объекту.
Когда явно выбирать композицию:
- Поведение должно быть составлено из нескольких несвязанных аспектов.
- Требуется менять реализацию в рантайме или маркерная гибкость (подстановка разных реализаций).
- Базовый класс не стабилен или его внутренности не хочется наследовать.
- Нужна множественная «наследственность» поведения (в Java композиция + интерфейсы).
Рекомендации практического выбора (короткий чек‑лист):
- Если не уверены в строгом «is‑a» — используйте композицию.
- Если нужен полиморфизм по типу и соблюдение контрактов — используйте наследование/интерфейсы.
- Для повторного использования кода предпочитайте композицию + интерфейсы; когда общая часть — семантически общая сущность — используйте абстрактный класс.
Пример композиции вместо наследования:
class A { void m() { /*...*/ } }
class B {
private final A a;
B(A a) { this.a = a; }
void m() { a.m(); /*...*/ } // делегирование
}
Итог: наследование — мощный инструмент, но рискованный; используйте его для реального подтипа с неизменным контрактом. В остальных случаях чаще выбирайте композицию (делегирование) для гибкости и устойчивости к изменениям.