Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Коли Mediator призводить до ускладнення архітектури?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)Патерн **Mediator (Посередник)** починає **ускладнювати архітектуру**, коли кількість взаємодій і логіки, переданих йому, **перевищує розумну межу** - тобто коли він перетворюється не на координатора, а на **центральний мозок системи**, від якого залежить усе. **Ключове:** Mediator корисний, поки залишається "розпорядником"; щойно він стає "володарем усіх взаємодій", архітектура втрачає гнучкість і прозорість.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)ЗображенняПатерн **Mediator (Посередник)** починає **ускладнювати архітектуру**, коли кількість взаємодій і логіки, переданих йому, **перевищує розумну межу** - тобто коли він перетворюється не на координатора, а на **центральний мозок системи**, від якого залежить усе. --- ### 1. **Коли посередник керує надто багатьма компонентами** Якщо через Mediator проходять десятки різних об'єктів і подій, у ньому накопичуються всі залежності і сценарії їхньої взаємодії. Він перестає бути посередником і стає **глобальним контролером**, де будь-яка правка одного модуля вимагає змін у посереднику. > *Приклад:* GUI-форма з 15 елементами, де Mediator керує всіма ними: > полями, кнопками, списками, діалогами - сотні умов `if` і розгалужень. --- ### 2. **Коли Mediator бере на себе бізнес-логіку** Посередник повинен керувати **взаємодією**, а не **самою поведінкою** компонентів. Якщо через нього починають реалізовувати бізнес-правила ("якщо статус замовлення X - оновити склад і повідомити користувача"), він перетворюється на **монолітний шар логіки**, який складно тестувати і розширювати. > Ознака: Mediator знає "занадто багато" про внутрішній устрій усіх учасників. --- ### 3. **Коли всі зміни вимагають модифікації посередника** Якщо при додаванні нового компонента, поля чи кнопки доводиться переписувати Mediator - це означає, що він став **вузьким місцем архітектури** і порушує принцип відкритості/закритості (OCP). > Зрештою Mediator стає точкою крихкості: одна зміна ламає кілька сценаріїв. --- ### 4. **Коли взаємодії стають неявними** У системах з великими Mediator-об'єктами поведінка компонентів стає "магічною" - важко зрозуміти, хто кого повідомляє і чому. Щоб відстежити ланцюжок викликів, доводиться перегортати сотні рядків посередника. > Це знижує читабельність і робить налагодження виснажливим. --- ### 5. **Коли посередників стає занадто багато** У великих системах часто з'являється декілька Mediator'ів (на рівні UI, домену, інфраструктури). Якщо вони починають залежати один від одного, архітектура перетворюється на **шаруватий клубок посередників**, де логіка дублюється і плутається. --- ### **Ознаки, що Mediator став шкідливим** - Великий клас із сотнями рядків і десятками `if/else`. - Залежності на всі компоненти системи. - Складно тестувати чи додати нову взаємодію. - Компоненти перестали бути переоснащуваними без свого посередника. --- ### **Висновок** Патерн **Mediator** ускладнює архітектуру, коли: - у ньому концентрується **забагато логіки і зв'язків**, - він починає **порушувати принципи SRP і OCP**, - і замість *координатора* перетворюється на *диригента всього застосунку*. **Підсумок:** > Mediator корисний, поки залишається "розпорядником". > Щойно він стає "володарем усіх взаємодій" - > архітектура втрачає гнучкість і прозорість.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.