Це з ВІКІ

{Патерн проектування спостерігача - це поведінковий патерн, що

входить до 23 відомих патернів проектування "Банди чотирьох", які
вирішують повторювані проблеми проектування з метою створення
гнучкого та багаторазового об'єктно-орієнтованого програмного
забезпечення, створюючи об'єкти, які легше впроваджувати,
змінювати, тестувати та повторно використовувати[1].

Шаблон спостерігача вирішує такі проблеми:[2].

● Залежність "один-до-багатьох" між об'єктами повинна бути

визначена без того, щоб об'єкти були тісно пов'язані між собою.
● Коли один об'єкт змінює стан, необмежена кількість залежних
об'єктів повинна автоматично оновлюватися.
● Об'єкт може повідомляти декілька інших об'єктів.

Визначення залежності між об'єктами типу "один до багатьох" шляхом

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

● Визначте об'єкти " Суб 'єкт" та " Спостерігач ".

● Коли суб'єкт змінює стан, всі зареєстровані спостерігачі
отримують повідомлення і оновлюються автоматично (і,
можливо, асинхронно).

Єдиним обов'язком суб'єкта є ведення списку спостерігачів та

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

Слайд№4:

Клієнт може щодня відвідувати магазин і перевіряти наявність товару.

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

Слайд№5:

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

Шаблон Observer передбачає, що ви додаєте механізм підписки до

класу видавця, щоб окремі об'єкти могли підписуватися або
відписуватися від потоку подій, що надходять від цього видавця. Не
бійся! Все не так складно, як здається. Насправді цей механізм
складається з 1) поля масиву для зберігання списку посилань на
об'єкти абонента і 2) декількох публічних методів, які дозволяють
додавати абонентів і видаляти їх з цього списку.
Після малюнку:

Тепер, коли важлива подія відбувається з видавцем, він проходить

через своїх передплатників(subscribers) і викликає конкретний метод
повідомлення на своїх об'єктах.

Реальні програми можуть мати десятки різних класів

підписників(subscribers), які зацікавлені в відстеженні подій одного
класу видавців(publishers). Ви б не хотіли поєднати видавця(publishers)
з усіма цими класами. Крім того, ви можете навіть не знати про деякі з
них заздалегідь, якщо ваш клас видавця(publisher) повинен бути
використаний іншими людьми.

Слайд№6 (Продовження Рішення):

Ось чому дуже важливо, щоб всі передплатники(subscribers)

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

Якщо ваш додаток має кілька різних типів видавців(publishers), і ви

хочете, щоб ваші передплатники(subscribers) були сумісні з усіма з
них, ви можете піти ще далі і змусити всіх видавців(publishers)
слідувати одному інтерфейсу. Цей інтерфейс повинен описати лише
кілька методів підписки. Інтерфейс дозволить передплатникам
спостерігати за станами видавців без прив'язки до конкретних класів.

Слайд№7 :

Якщо ви підписалися на газету або журнал, вам більше не потрібно

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

Слайд№8 :

1) Видавець(Publisher) видає події, що представляють інтерес для

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

2) Коли відбувається нова подія, видавець переходить по списку

підписки і викликає метод повідомлення, заявлений в інтерфейсі
абонента на кожному об'єкті абонента.

3) Інтерфейс абонента(subscriber) оголошує інтерфейс повідомлення.

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

4) Конкретні абоненти(Concrete Subscribers) виконують деякі дії у

відповідь на повідомлення видавця. Всі ці класи повинні реалізовувати
один і той же інтерфейс, тому видавець не пов'язаний з конкретними
класами.

5) Зазвичай абонентам потрібна певна контекстна інформація для

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

6) Клієнт створює об'єкти видавця і абонента окремо, а потім реєструє

абонентів для оновлення видавця.

Слайд№9:

Використовуйте паттерн Спостерігач, коли зміна стану одного

об'єкта може призвести до зміни інших об'єктів, а реальний набір
об'єктів заздалегідь невідомий або змінюється динамічно.
Часто з такою проблемою можна зіткнутися при роботі з класами
графічного інтерфейсу користувача. Наприклад, ви створили власні
класи кнопок і хочете дозволити клієнтам під'єднати до ваших кнопок
власний код, щоб він спрацьовував щоразу, коли користувач натискає
кнопку.

Паттерн "Спостерігач" дозволяє будь-якому об'єкту, що реалізує

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

Використовуйте шаблон, коли одні об'єкти у вашому додатку

повинні спостерігати за іншими, але лише протягом обмеженого
часу або в певних випадках.

Список підписок є динамічним, тому підписники можуть приєднуватися

до нього або виходити з нього, коли їм це потрібно.

Слайд№10:

Плюси:

1. Принцип відкритості/закритості: Паттерн Observer

дотримується принципу відкритості/закритості, дозволяючи
вводити нові класи підписників без необхідності внесення змін до
коду видавця. Аналогічно, зміни в інтерфейсі видавця можуть
бути внесені без впливу на існуючі класи передплатників. Це
сприяє розширюваності коду і зменшує ризик появи помилок при
розширенні системи.
2. Динамічні зв'язки: Паттерн Observer дозволяє встановлювати
динамічні зв'язки між об'єктами під час виконання програми.
Видавці та передплатники можуть бути вільно пов'язані між
собою, що забезпечує гнучку та динамічну взаємодію. Це
полегшує розробку систем, де зв'язки між об'єктами можуть
динамічно змінюватися залежно від умов виконання або дій
користувача.

Мінуси:
 1. Випадковий порядок сповіщень: Одним з основних недоліків
патерну Observer є те, що підписники отримують сповіщення у
випадковому порядку. Ця відсутність детермінованості може
ускладнити передбачення послідовності, в якій підписники
отримуватимуть сповіщення. Як наслідок, підписники повинні
обробляти сповіщення незалежно один від одного, що може
ускладнити розробку і тестування системи.

Слайд№11:

Висновки

В шаблоні Observer ми спостерігаємо, як об'єкти спілкуються,

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