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

1. Розглянемо контекстно-залежну оперативну довідку в графічному інтерфейсі користувача, що надає можливість одержати додаткову інформацію про будь-яку частину інтерфейсу, просто клацнувши по ній мишею. Зміст довідки залежить від того, яка частина інтерфейсу й в якому контексті обрана. Наприклад, довідка про кнопку в діалоговому вікні може відрізнятися від довідки про аналогічну кнопку в головному вікні додатка. Якщо для деякої частини інтерфейсу довідки немає, то система повинна показати інформацію про найближчий контекст, в якому вона знаходиться, наприклад про діалогове вікно в цілому. Тому природно було б організувати довідкову інформацію від більш конкретних розділів до більш загальних. Крім того, ясно, що запит на одержання довідки обробляється одним з декількох об’єктів користувальницького інтерфейсу, яким саме – залежить від контексту і наявної інформації.

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

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

Ідея рішення полягає в тому, щоб розірвати зв’язок між відправниками й одержувачами, давши можливість обробити запит декільком об’єктам. Запит переміщається по ланцюжку об’єктів, поки один з них не обробить його. Перший об’єкт у ланцюжку одержує запит і або обробляє його сам, або направляє наступному кандидату в ланцюжку, який чинить точно так само. В об’єкта, що відправив запит, відсутня інформація про оброблювача. Тобто в запиту є анонімний одержувач (іmplіcіt receіver) – посилання на об’єкт, що його зрештою виконає. Щоб відправити запит по ланцюжку і гарантувати анонімність одержувача, всі об’єкти в ланцюжку мають єдиний інтерфейс для обробки запитів і для доступу до свого спадкоємця (наступному об’єкту в ланцюжку).

2. Програмне забезпечення для роботи банкомату теж може бути реалізоване з використанням принципів паттерна Chaіn of Responsіbіlіty. Банкомат має завантажувальні контейнери для купюр різного номіналу. Механізм видачі грошей полягає в тому, що клієнт задає суму для видачі, ця сума формується з наявних купюр, починаючи з купюр найбільшого номіналу. Якщо який-небудь контейнер уже порожній, то видача грошей відбувається з наступного заповненого контейнера (рис. 6.1).

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

Тобто мається потік запитів і змінна кількість «обробників» цих запитів. Необхідно ефективно обробляти запити без жорсткої прив’язки до їх обробників, при цьому запит може бути оброблений будь-яким обробником.

3. Нехай необхідно розробити архітектуру програмної системи для аналізу і розбору вхідних електронних повідомлень. Повідомлення поділяються на чотири види: вираження подяки від шанувальників, яким подобається нова гра; скарги від батьків, діти яких не на жарт захопилися грою, прохання про установку автоматів у нових місцях та спам. Усі повідомлення шанувальників повинні надходити керівництву, усі скарги – в юридичний відділ, а запити на установку – у відділ комерційного розвитку. Спам просто віддаляється.

Задача проектувальника архітектури полягає в наступному: маючи евристичні детектори, що визначають, до якого виду відноситься повідомлення необхідно застосувати ці детектори для обробки вхідної пошти. Для розв’язання цього завдання можна скористатися архітектурою паттерна Ланцюжок відповідальностей та створити ланцюжок об’єктів-обробників запитів, які один за одним проаналізують вхідне повідомлення. Якщо вид повідомлення відповідає обробнику буде здійснена його обробка, інакше – повідомлення передається наступному об’єкту-обробнику (рис. 6.2).

Рис 6.2. Схема передачі оброки запитів у предметній області

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

Рис. 6.3. Схема передачі запитів в паттерні

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

Паттерн Chain of Responsibility пов’язує в ланцюжок об’єкти-одержувачі, а потім передає запит-повідомлення від одного об’єкта до іншого доти, поки не буде досягнуто об’єкта, здатного його обробити. Кількість і типи об’єктів-обробників заздалегідь невідомі, вони можуть налаштовуватися динамічно. Механізм зв’язування в ланцюжок використовує рекурсивну композицію, що дозволяє використовувати необмежену кількість обробників.

Паттерн Chain of Responsibility спрощує взаємозв’язок між об’єктами. Замість зберігання посилань на всіх кандидатів-одержувачів запиту, кожний відправник зберігає єдине посилання на початок ланцюжка, а кожний одержувач має єдине посилання на свого наступника – наступний елемент в ланцюжку.

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

Загальна структура паттерна представлена у вигляді діаграми класів на рис. 6.4:

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

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