Учасники паттерна. - знає, яким класам підсистеми адресувати запит;

1. Facade – фасад:

- знає, яким класам підсистеми адресувати запит;

- делегує запити клієнтів відповідним об’єктам всередині підсистеми.

2. Класи підсистеми:

- реалізують функціональність підсистеми;

- виконують роботу, доручену об’єктом Facade;

- нічого не знають про існування фасаду, тобто не зберігають посилань.

Відносини учасників паттерна. Клієнти спілкуються з підсистемою, посилаючи запити фасаду. Він переадресує їх відповідним об’єктам всередині підсистеми. Хоча основну роботу виконують саме об’єкти підсистеми, фасаду, можливо, доведеться перетворити свій інтерфейс до інтерфейсів підсистеми.

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

Рис. 5.24. Діаграма послідовності для паттерна Фасад

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

Необов’язково клас фасаду повинний зберігати в собі об’єкти класів підсистеми. Доступ до об’єктів підсистеми можна облаштувати через паттерн Proxy. Також іноді програмісти роблять клас фасаду статичним, для того, щоб до нього можна було звернеться з будь-якої точки програми.

Особливості програмної реалізації. При реалізації фасаду слід звернути увагу на [12, 24]:

- зменшення ступеня зв’язаності клієнта з підсистемою. Ступінь зв’язаності можна значно зменшити, якщо зробити клас Facade абстрактним. Його конкретні підкласи будуть відповідати різним реалізаціям підсистеми. Тоді клієнти зможуть взаємодіяти з підсистемою через інтерфейс абстрактного класу Facade. Це ізолює від клієнтів інформацію про те, яка реалізація підсистеми використовується.

Результати використання. Застосування паттерна Фасад надає:

- контроль за використанням системи. Змушуючи користувачів усі звертання до системи виконувати тільки через клас Facade, легко можна контролювати їхній доступ до неї;

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

Фасад запобігає появі сильних зв’язків між клієнтом і підсистемою і, сприяє дотриманню принципу ООП – принципу мінімальної інформованості. Що це означає на практиці? Що при проектуванні системи для будь-якого об’єкта варто звернути особливу увагу на кількість класів, з якими він взаємодіє, і яким образом організована ця взаємодія. Цей принцип перешкоджає створенню архітектур з великою кількістю тісно зв’язаних класів, в яких зміна в одній частині системи каскадно поширюється в інші частини. При формуванні численних залежностей між класами система втрачає гнучкість і стає складної для розуміння, а витрати на її супровід зростають. Але як домогтися цієї мети? Принцип дає деякі рекомендації. Візьмемо довільний об’єкт; відповідно до принципу, з будь-якого методу цього об’єкта повинні викликатися тільки методи, що належать:

- самому об’єктові;

- об’єктам, переданим у параметрах методу;

- будь-якому об’єкту, створеному всередині методу;

- будь-яким компонентам об’єкта.

Паттерн Декоратор (Decorator)

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

Частота використання

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

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

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

- невиправданому розростанню класів;

- негнучкій архітектурі;

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

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

Рис. 5.25. Схема надання нової функціональності

Кожний об’єкт Декоратор як би «упаковує» вихідний об’єкт у нову функцію. Окремий об’єкт декоратор виконує свою додану функціональність або перед виконанням функції декоратора, або після її виконання.

Проблемні предметні області.

1. Паттерн Decorator динамічно додає нові обов’язки об’єкту. Прикраси для новорічної ялинки є прикладами декораторів. Прикраси не змінюють саму ялинку, а тільки роблять її новорічною. Також хоча картини можна повісити на стіну і без рамок, рамки часто додаються для додання нового стилю (рис. 5.26), що може також розглядатися як паттерн Декоратор реального світу.

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

2. Розглянемо докладніше наступну проблемну область: нехай необхідно створити програмну систему для обчислення вартості напоїв у кафе. Нехай у кафе вже мається ПС з наступною архітектурою (рис. 5.27) [10].

Рис. 5.27. Діаграма класів проблемної предметної області

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

Кожний метод cost() розраховує вартість напою разом із будь-яким додатковим компонентом. Така архітектура має безліч недоліків і подальше розширення асортименту, зробить систему ще складнішою. Тому необхідно застосувати більш оптимальне рішення. Почнемо з базового напою і «декоруємо» його на стадії виконання. Наприклад, якщо клієнт замовляє каву темного обсмаження (Dark Roast) із шоколадом (Mocha) і збитими вершками (Whіp), то необхідно здійснити наступні програмні дії:

Рис. 5.28. Розширення структури предметної області

- беремо об’єкт DarkRoast. Наголошуємо, що DarkRoast є нащадком від Beverage і містить метод cost() для розрахунку вартості базового напою;

- декоруємо його об’єктом Mocha. Тобто створюємо об’єкт Mocha і «загоратємо» до нього об’єкт DarkRoast. Об’єкт Mocha є декоратором. Його тип повторює тип об’єкта, що декорується – в даному випадку Beverage;

- декоруємо його об’єктом Whip. Створюємо об’єкт Whip і «загортаємо» до нього об’єкт Mocha. Декоратор Whip також повторює тип DarkRoast і містить метод по розрахунку вартості напою.

Таким чином об’єкт DarkRoast, «огорнутий» в Mocha і Whip, зберігає признаки Beverage і з ним можна роботи все, що можна робити з DarkRoast, включаючи метод cost ();

- викликаємо метод cost() зовнішнього декоратора Whіp, і користуємося делегуванням для додавання вартості доповнень Для цього:

· спочатку cost() викликається для зовнішнього декоратора Whіp;

· Whіp викликає метод cost() для об’єкта Mocha;

· об’єкт Mocha викликає метод cost() для об’єкта DarkRoast;

· об’єкт DarkRoast повертає свою вартість;

· об’єкт Mocha додає свою вартість до результату, отриманому від DarkRoast, і повертає отриману суму;

· об’єкт Whіp додає свою вартість до отриманого результату і повертає загальну суму.

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

Рис. 5.29. Предметна область в термінах паттерна Декоратор

Отже паттерн Декоратор динамічно наділяє об’єкт новими можливостями і є гнучкою альтернативою субкласування в області розширення функціональності.

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

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