Чем композиция отличается от наследования и можно ли обойтись без наследования?

Наследование и композиция — два способа переиспользовать уже написанный код. Наследование строит иерархию типов: класс-потомок автоматически получает поля и методы родителя и может их переопределять. Композиция вместо этого собирает объект из других объектов: класс хранит ссылки на помощников и вызывает их методы. Ключевое различие — в типе связи: наследование выражает отношение "является" (is-a), композиция — "содержит" (has-a).

Почему композицию часто предпочитают

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

Пример на TypeScript

// Наследование: жёсткая иерархия
class Animal {
  move() { console.log('moving'); }
}
class Dog extends Animal {
  bark() { console.log('woof'); }
}

// Композиция: гибкая сборка
interface Mover { move(): void; }
class Walker implements Mover {
  move() { console.log('walking'); }
}
class Dog2 {
  constructor(private mover: Mover) {}
  move() { this.mover.move(); }
  bark() { console.log('woof'); }
}
const dog = new Dog2(new Walker());
dog.move(); // walking

Когда наследование всё же уместно

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

Полностью обойтись без наследования можно: интерфейсы, трейты, миксины и делегирование покрывают почти все задачи. Но в некоторых языках и фреймворках (например, Java-коллекции, исключения, UI-компоненты) наследование остаётся естественным и удобным инструментом.

Итог: применяйте композицию по умолчанию — она даёт гибкость и слабую связанность; наследование оставляйте для случаев, где действительно есть устойчивая иерархия типов и общий контракт.