Яка різниця між композицією та наслідуванням?

Повне пояснення

Що це і навіщо

Композиція та наслідування – два фундаментальних патерни об’єктно‑орієнтованого дизайну. Вони допомагають організувати код, забезпечуючи реюзабельність і розширюваність.

Ключові принципи

• Наслідування (inheritance): клас‑потомок отримує всі члени базового класу. Це «is‑a» зв’язок.
• Композиція (composition): клас містить інші об’єкти як поля. Це «has‑a» зв’язок.

Як це працює

• Наслідування: під час компіляції створюється ієрархія, а методи викликаються через віртуальний таблицю (vtable). Перевага – простота, недосяжність поліморфізму.
• Композиція: об’єкт створюється, а потім «передає» відповідальність іншим об’єктам. Перевага – більша гнучкість, менше залежностей.

Практика і реалізація

// Наслідування
class Vehicle { move() {} }
class Car extends Vehicle { honk() {} }

// Компонування
class Engine { start() {} }
class Car {
  constructor(private engine: Engine) {}
  drive() { this.engine.start(); }
}

Тестування

import { describe, it, expect } from 'vitest';
describe('Car', () => {
  it('uses engine to drive', () => {
    const mockEngine = { start: vi.fn() };
    const car = new Car(mockEngine as any);
    car.drive();
    expect(mockEngine.start).toHaveBeenCalled();
  });
});

Дизайн‑рішення

• Якщо поведінка є загальною і не змінюється, використовуйте наслідування.
• Якщо поведінка змінювана або потрібна мульти‑параметрична конфігурація, використовуйте композицію.

Оптимізація та edge‑cases

• Наслідування створює тверді зв’язки, що ускладнюють тестування.
• Композиція дозволяє легко мокати залежності, але потребує більше коду для проксування.

Диагностика

• Симптом: «під час зміни базового класу падає багато тестів» → причина: сильна залежність через наслідування.
• Дія: розділити поведінку на окремі сервіси і використати композицію.

Альтернативи

• Патерн «Strategy» – композиція з функціональними об’єктами.
• Патерн «Decorator» – композиція для розширення функціональності без наслідування.

Часті помилки

1. Перевантаження наслідування там, де потрібна композиція.
2. Використання protected полів замість інтерфейсів.
3. Залежність від конкретних реалізацій у базовому класі.
4. Необхідність змінювати базовий клас для додавання нових функцій.
5. Переважання «extends» над «implements» у TypeScript.
6. Втрата типобезпеки через any в композиції.
7. Неправильне використання super() у конструкторі.
8. Занадто глибока ієрархія класів, що ускладнює розуміння коду.