Що станеться, якщо фасад стане занадто «товстим»?
Якщо фасад стає занадто «товстим» - тобто бере на себе занадто багато обов'язків - він перетворюється на "божественний об'єкт" (God Object), і це призводить до низки проблем в архітектурі.
1. Порушення принципу єдиної відповідальності (SRP)
Фасад починає керувати всім підряд: бізнес-логікою, даними, помилками, транзакціями. У підсумку він перестає бути інтерфейсом і стає центром усієї логіки системи, що робить код важким у підтримці й крихким.
2. Зниження модульності
Якщо занадто багато компонентів зав'язані на один фасад, будь-які його зміни починають ламати залежні модулі. Таким чином, фасад перетворюється на точку жорсткої зв'язаності, а не ізоляції.
3. Ускладнене тестування
Коли фасад керує занадто багатьма підсистемами, протестувати його ізольовано стає майже неможливо: доводиться піднімати половину застосунку.
4. Втрата прозорості
Уся логіка виявляється схованою "за фасадом", і зрозуміти, що реально відбувається під капотом, складно. Це ускладнює налагодження і робить поведінку системи менш передбачуваною.
5. Уповільнення розвитку системи
Через високу зв'язаність і обсяг коду будь-який новий сценарій вимагає змін саме у "фасаді", що суперечить принципу відкритості/закритості (OCP).
Як уникнути
- Ділити фасади за контекстами (наприклад,
UserFacade,PaymentFacade,ReportFacade). - Залишати у фасаді тільки координацію дій, а не бізнес-логіку.
- Стежити, щоб фасад залишався інтерфейсом, а не "міні-монолітом".
Підсумок: "Товстий" фасад перестає спрощувати систему: він ускладнює її, створює нову точку залежності і порушує архітектурну ізоляцію. Хороший фасад повинен координувати, а не контролювати все.
Коротка відповідь
Для співбесідиКоротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.