Які проблеми вирішує Observer?

Патерн Observer (Спостерігач) вирішує одразу декілька ключових проблем, пов'язаних із зв'язаністю, синхронізацією стану і реактивністю системи.

---

#1. Проблема сильної зв'язаності між об'єктами

Без Observer кожен об'єкт, якому потрібно реагувати на зміни іншого, повинен напряму знати:

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

Це створює щільну мережу залежностей - будь-яка зміна у видавцеві вимагає переписування коду всіх слухачів.

#Як вирішує

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

Результат - слабка зв'язаність: видавець і підписники незалежні й легко замінні.

---

#2. Проблема синхронізації стану між пов'язаними об'єктами

Коли у декількох компонентів спільний стан (наприклад, модель і інтерфейс), важко гарантувати, що всі вони будуть в актуальному стані після зміни даних.

#Як вирішує

Observer забезпечує автоматичне оновлення: при зміні видавець розсилає сповіщення всім підписникам, і вони синхронно приводять свої дані у відповідність.

Приклад: зміна моделі даних у MVC викликає автоматичне оновлення всіх представлень.

---

#3. Проблема жорсткого порядку викликів і прямого керування

Без патерну об'єкти повинні вручну координувати оновлення, визначаючи порядок, пріоритет і момент виклику. Це ускладнює логіку і збільшує ризик помилок при змінах.

#Як вирішує

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

"Подія сталася" → "усі, кому це важливо, оновилися самі".

---

#4. Проблема масштабування сповіщень

При ручному керуванні подіями складно розширити систему: додавання нового слухача вимагає правок у видавцеві.

#Як вирішує

Механізм підписки робить додавання нових спостерігачів динамічним: нові об'єкти можуть підписуватися і відписуватися під час виконання, без зміни наявного коду.

---

#5. Проблема розподілу відповідальності

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

#Як вирішує

Observer чітко розділяє ролі:

• видавець відповідає за дані,
• спостерігачі - за реакцію на зміни.

Це основа архітектури MVC: Модель → View (через Observer).

---

#Підсумок

Патерн Observer вирішує такі проблеми:

---

Висновок: Патерн Observer робить систему гнучкою, реактивною і розширюваною, прибираючи жорсткі залежності і перетворюючи прямі виклики на автоматичну реакцію на події.