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