Проблемні предметні області. 1. У Unіx права доступу до системних ресурсів визначаються трьома рівнями: власник, група та інші

1. У Unіx права доступу до системних ресурсів визначаються трьома рівнями: власник, група та інші. Група є сукупністю користувачів, що володіють деякою функціональною приналежністю [14]. Кожний користувач у системі може бути членом однієї або декількох груп, і кожна група може мати 0 або більше користувачів, призначених цій групі. Наступний рисунок показує трьох користувачів, що є членами всіх трьох груп (рис. 6.24).

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

Якщо нам потрібно було б побудувати програмну модель такої системи, то ми могли б зв’язати кожний об’єкт User з кожним об’єктом Group, а кожний об’єкт Group – з кожним об’єктом User. Однак через наявність безлічі взаємозв’язків модифікувати поведінку такої системи дуже непросто, довелося б змінювати всі існуючі класи.

Альтернативний підхід – уведення «додаткового рівня зв’язку» або побудова абстракції з відображенням (відповідності) користувачів у групі і групи у користувачів. Такий підхід має наступні переваги: користувачі і групи відділені один від одного, відображеннями легко керувати одночасно й абстракція відображення може бути розширена в майбутньому шляхом визначення похідних класів (рис. 6.25).

Рис. 6.25. Застосування паттерна до проблемної предметної області

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

Приклад раціонального використання паттерна Medіator – моделювання відносин між користувачами і групами операційної системи. Група може мати 0 або більше користувачів, а користувач може бути членом 0 або більше груп. Паттерн Medіator передбачає гнучкий спосіб керування користувачами і групами.

2. Розумний будинок [10]. «Розумний будинок» з недалекого майбутнього можна описати так: усі домашні прилади і пристрої сконструйовані так, щоб зробити життя якомога більш комфортним. Коли власник будинку відключає сигнал будильника, то будильник наказує кавоварці приступити до готування кави і т.д. і т.п. Але незважаючи на всі зручності, власник хоче не варити каву по вихідним. Відключити зрошувальну систему за 15 хвилин до прийняття душу. Ставити будильник на більш ранній час у дні вивозу сміття.

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

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

Включення Посередника в систему значно спрощує всі об’єкти пристроїв:

- об’єкти пристроїв сповіщають посередника про зміну свого стану;

- об’єкти пристроїв відповідають на запити посередника.

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

замість:

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

3. Розглянемо реалізацію діалогових вікон у графічному інтерфейсі користувача. Тут розташовується ряд віджетів: кнопки, меню, поля введення і т.д.

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

В різних діалогових вікнах залежності між віджетами можуть бути різними. Тому, незважаючи на те, що у всіх вікнах зустрічаються однотипні віджети, просто взяти і повторно використовувати готові класи віджетів не вдасться, прийдеться робити настроювання з метою обліку залежностей. Індивідуальне настроювання кожного віджета – стомлююче заняття, тому що класів, що беруть участь, занадто багато.

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

Структура паттерна представлена на діаграмі класів паттерна (рис. 6.27).

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

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