Проблемні предметні області. 1.Підписка на газету або журнал:

1. Підписка на газету або журнал:

- видавець відкриває свою справу і починає випускати газету;

- передплатник оформляєте підписку в конкретного видавця. Щораз, коли виходить новий номер, він доставляється йому. Поки підписка діє, він одержуєте нові випуски газети;

- якщо передплатник не хочете більше одержувати газету, він припиняєте підписку;

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

Якщо є розуміння того, як працює газетна підписка, то значною мірою є розуміння і паттерну Спостерігач – тільки в рамках термінології паттерна видавець називається суб’єктом, а передплатники – спостерігачами.

2. Припустимо, що при оновленні додатка підтримки електронної торгівлі була висунута чергова нова вимога. З’ясувалося, що необхідно виконувати перераховані нижче дії всякий раз, коли до системи підключається новий клієнт:

- послати клієнту ввічливе запрошення по електронній пошті;

- перевірити адресу клієнта за списком поштових відділень.

При цьому не має впевненості у тому, що тепер усі вимоги до системи уже відомі.

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

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

- різні види об’єктів. Існують об’єкти, які необхідно повідомити про зміни стану системи. Ці об’єкти, як правило, належать до різних класів;

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

Для організації гнучкої архітектури програмної системи доцільно скористатися принципами організації паттерна Спостерігач. Насамперед, необхідно виявити всі об’єкти, які повинні одержувати повідомлення і назвати їх спостерігачами (оbserver) тому, що вони знаходяться в стані чекання деякої події, яка повинна відбутися. Це дозволить додавати нові об’єкти-спостерігачі без будь-якого впливу на будь-які вже існуючі класи. Це також дозволить підтримувати в системі низький рівень зв’язаності. Організована подібним чином система працює так, щоб всі об’єкти в ній відповідали тільки самі за себе.

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

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

Паттерн Observer визначає об’єкт Subject, що зберігає дані (модель), а всю функціональність делегує слабозв’язаним окремим об’єктам Observer. В ході роботи додатку спостерігачі Observer реєструються в об’єкта Subject. Коли об’єкт Subject змінюється, він сповіщає про це всіх зареєстрованих спостерігачів. Після цього кожний спостерігач запитує в об’єкта Subject ту частину стану, яка необхідна для відображення даних.

Суб’єкт і спостерігачі описуються відношенням «один-до-багатьох». Спостерігачі залежать від суб’єкта: при зміні стану останнього спостерігачі одержують оповіщення. В залежності від способу оповіщення також можливе відновлення стану спостерігачів (рис. 6.22) [10].

Рис. 6.21. Схема предметної області

Рис. 6.22. Схема предметної області в термінах паттерна Спостерігач

Коли стан одного об’єкта змінюється, всі залежні об’єкти отримують оповіщення. Загальна структура паттерна представлена на діаграмі класів на рис. 6.23.

Рис. 6.23. Діаграма класів паттерна

Поиск по сайту: