Поліморфізм в ООП: як змусити код “працювати з усім” і не зійти з розуму (майже)

Поліморфізм — це магічне слово, яким інженери пояснюють, чому одна й та сама функція може поводитися по-різному залежно від того, який саме об’єкт до неї прийшов на співбесіду. І все це — без того, щоб писати 17 if/else, 42 switch і один “тимчасовий хак”, який живе у продакшені третій рік.

Нижче — технічний розбір поліморфізму, типів, практик і типових пасток. Без зайвої романтики, але з достатньою кількістю прикладів, щоб не довелося йти в коментарі на Stack Overflow за моральною підтримкою.

---

Що таке поліморфізм (людською мовою)

Поліморфізм (від грец. “багато форм”) — це здатність коду працювати з об’єктами різних типів через спільний інтерфейс, не знаючи (або майже не знаючи), що саме всередині.

Коротко:

• Ви пишете код проти абстракції (інтерфейсу/базового класу),
• а реальна поведінка визначається конкретною реалізацією під час виконання (або компіляції — залежить від виду поліморфізму).

Найпопулярніша формула в ООП-міфології звучить так:

“Код, який не знає, з чим працює, але все одно якось працює”.

---

Навіщо він потрібен

Поліморфізм потрібен не для того, щоб писати “красиво”. Він потрібен для:

1. Розширюваності: додали новий тип — старий код не чіпаємо.
2. Зменшення зв’язності: залежність від контракту, а не від реалізації.
3. Заміни умовної логіки (if type == ...) на диспетчеризацію методів.
4. Тестованості: легше підміняти реалізації (mock/stub/fake).
5. Підтримки принципів SOLID, зокрема Open/Closed та Liskov.

---

Основні види поліморфізму

У більшості мов ООП його умовно ділять на:

1. Підтиповий поліморфізм (subtype polymorphism) — через наслідування/інтерфейси.
2. Параметричний (parametric polymorphism) — generics / шаблони.
3. Ad-hoc поліморфізм — перевантаження функцій/операторів (overloading).
4. Duck typing / structural typing (в деяких мовах) — “якщо крякає, то качка”.

Розглянемо головні техніки на практиці.

---

1) Підтиповий поліморфізм: інтерфейс + різні реалізації

Класичний сценарій: є базовий контракт, і кілька типів, які реалізують його по-своєму.

Приклад (Java / Kotlin-стиль псевдокоду)

interface PaymentMethod {
    void pay(int amount);
}

class CardPayment implements PaymentMethod {
    public void pay(int amount) {
        System.out.println("Paying " + amount + " by card");
    }
}

class ApplePayPayment implements PaymentMethod {
    public void pay(int amount) {
        System.out.println("Paying " + amount + " via Apple Pay");
    }
}

class CheckoutService {
    private final PaymentMethod payment;

    CheckoutService(PaymentMethod payment) {
        this.payment = payment;
    }

    void checkout(int amount) {
        payment.pay(amount);
    }
}

Що тут поліморфного?
CheckoutService працює з PaymentMethod, не знаючи, чи там карта, Apple Pay, чи завтра буде “Оплата котом”. Головне — щоб реалізація дотримувалась контракту pay().

Ключова користь

Ви додаєте CryptoPayment, і CheckoutService не переписується. Це і є “Open for extension, closed for modification” у живому середовищі.

---

Поліморфізм проти switch: де виграє дизайн

Поганий (але дуже популярний) спосіб:

def pay(method_type, amount):
    if method_type == "card":
        ...
    elif method_type == "apple_pay":
        ...
    elif method_type == "crypto":
        ...

Ви додаєте новий метод — ви модифікуєте цю функцію. І якщо така функція — у трьох місцях, то ви тепер модифікуєте три.

Поліморфізм дозволяє перетворити це на: “додай новий клас — і йди пити чай”.

---

2) Параметричний поліморфізм (Generics): “працюю з будь-яким T”

Це коли функція/клас працює з типом, який підставляється як параметр.

Приклад (TypeScript)

function first<T>(items: T[]): T | undefined {
  return items[0];
}

const a = first<number>([1, 2, 3]);
const b = first<string>(["a", "b"]);

Тут поведінка однакова, але типи — різні.
Це не “динамічна магія”, а контрольована універсальність, яку компілятор підтримує.

Де корисно

• колекції (List<T>, Map<K,V>)
• репозиторії/DAO
• серіалізація
• обробники подій
• пайплайни даних

---

3) Ad-hoc: перевантаження (overloading) і оператори

У багатьох мовах (Java, C#, C++) можна оголошувати методи з однаковим ім’ям, але різними параметрами:

void Print(int x) { ... }
void Print(string s) { ... }

Це поліморфізм часу компіляції: компілятор вибирає метод за сигнатурою.

Плюси:

• зручно для API (наприклад, WriteLine) Мінуси:
• легко зробити неоднозначність
• інколи маскує поганий дизайн (“а давайте ще 12 overload-ів…”)

---

Динамічна диспетчеризація: як ООП “вирішує”, який метод викликати

Коли ви пишете:

PaymentMethod m = new ApplePayPayment();
m.pay(100);

Фактично викликається метод конкретного класу ApplePayPayment, навіть якщо змінна типу PaymentMethod. Це називається dynamic dispatch (віртуальні методи).

Це механізм, який і робить підтиповий поліморфізм можливим.

---

Поліморфізм і LSP: як не “зламати” інтерфейс

Принцип підстановки Лісков (Liskov Substitution Principle) — найчастіше місце, де поліморфізм перестає бути другом і стає цікавим квестом.

Ідея: якщо B — підтип A, то об’єкти B мають бути взаємозамінними з A без поломки логіки.

Типова помилка: підклас звужує контракт.

Класичний “квадрат і прямокутник”

Якщо Square наслідує Rectangle, але змінює поведінку setWidth() / setHeight() так, що вони змінюють обидві сторони, — код, який очікує “прямокутні” гарантії, ламається.

Висновок: не всяка “логічна” ієрархія — коректна для наслідування.

---

Інтерфейси vs абстрактні класи: що вибирати для поліморфізму

Інтерфейс:

• задає контракт (що вміє об’єкт)
• дозволяє реалізувати кілька контрактів
• часто кращий для “плагінної” архітектури

Абстрактний клас:

• дає часткову реалізацію
• може зберігати стан
• корисно, коли є спільний код і ви контролюєте ієрархію

Практичне правило:

• “Мені потрібна поведінка як контракт” → інтерфейс
• “Мені потрібна база зі спільним кодом/даними” → абстрактний клас (обережно)

---

Поліморфізм у реальних патернах

Strategy (Стратегія)

Коли алгоритм міняється, а клієнтський код — ні.

• SortStrategy: quicksort/mergesort/…
• Compression: zip/gzip/brotli
• PricingPolicy: standard/discount/vip

Factory Method / Abstract Factory

Коли створення об’єктів теж поліморфне.

Visitor (обережно)

Дає “подвійний диспетчинг”, але часто додає складності. Корисний, якщо треба додавати нові операції над стабільною структурою типів.

---

Антипатерни: як поліморфізм перетворюється на цирк

1. God Interface
   Один інтерфейс на 40 методів “про всяк випадок”.

2. Fake inheritance
   Наслідування заради повторного використання коду, коли краще композиція.

3. Polymorphism for polymorphism’s sake
   Три абстракції, два рівні фабрик, один метод execute() — щоб надрукувати число.

4. Невірні гарантії контракту
   Підклас кидає винятки там, де базовий клас гарантував нормальну роботу.

---

Практичні поради: як застосовувати поліморфізм без болю

• Пишіть код проти інтерфейсу, не проти класу.
• Робіть інтерфейси малими (ISP: Interface Segregation Principle).
• Якщо вам постійно потрібні instanceof / is перевірки — можливо, у вас не поліморфізм, а лише його імітація.
• Ретельно формулюйте контракт: що гарантує метод, які інваріанти, які винятки.
• Там, де “є спільна поведінка” — розгляньте композицію (has-a) замість наслідування (is-a).
• Використовуйте generics там, де різниця лише у типі даних, а не в поведінці.

---

Короткий підсумок

Поліморфізм — це не “фішка ООП для презентацій”. Це механізм, який:

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

І якщо все зроблено правильно, то ваш код з часом не перетворюється на музей switch-case, а залишається системою, яку можна розширювати, не викликаючи екзорциста.

---

Якщо хочете, можу продовжити як наступний пост: “Поліморфізм vs композиція: як зрозуміти, що ви будуєте не ієрархію, а пастку”, або додати приклади конкретною мовою (Java/C#/Python/TypeScript/C++).