Коли патерн «Міст» може бути надлишковим?

Патерн Bridge (Міст) стає надлишковим, коли структура системи не вимагає відокремлення абстракції від реалізації, тобто коли гнучкість, заради якої він створюється, ніколи не буде реально використана.

---

#1. Коли ієрархія класів проста і стабільна

Якщо в системі є тільки одна реалізація і вона навряд чи зміниться, створення додаткових інтерфейсів та ієрархій тільки ускладнить код. Приклад: один клас Remote керує тільки одним типом TV - розділення не додасть користі, а лише створить надлишкову абстракцію.

---

#2. Коли немає потреби комбінувати варіанти

Bridge корисний, коли потрібно вільно поєднувати різні типи абстракцій і реалізацій (наприклад, різні пульти + різні пристрої). Якщо таких комбінацій немає, патерн втрачає сенс - достатньо звичайного успадкування або композиції.

---

#3. Коли код невеликий і рідко змінюється

Bridge додає щонайменше два рівні ієрархії (абстракцію і реалізацію). У невеликих проєктах або утилітах це створює зайве когнітивне навантаження: розуміння архітектури займає більше часу, ніж вона економить.

---

#4. Коли абстракція і реалізація природно пов'язані

Деякі об'єкти за своєю природою тісно пов'язані (наприклад, Order і OrderStatus). Штучне розбиття їх через інтерфейси може призвести до втрати ясності та надлишкового коду.

---

#5. Коли зміни простіше внести напряму

Якщо потрібно додати лише одну нову реалізацію, то впровадження Bridge заради цього - переінжиніринг. Простіше додати клас або поле, ніж створювати дві ієрархії.

---

#6. Висновок

Bridge варто застосовувати тільки тоді, коли реально потрібні:

• незалежний розвиток абстракції та реалізації,
• множинні комбінації класів,
• або підміна реалізацій під час виконання.

У решті випадків він лише збільшує складність, кількість класів і рівень абстракції, не приносячи архітектурних вигід.

Підсумок: Міст надлишковий, коли система проста, статична або не потребує незалежності шарів: тоді звичайне успадкування або композиція будуть простішими й ефективнішими.