Учасники паттерна. 1. Component– компонент:

1. Component – компонент:

- оголошує інтерфейс для компонованих об’єктів;

- надає відповідну реалізацію операцій, загальну для всіх класів;

- оголошує інтерфейс для доступу до нащадків і управління ними;

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

2. Leаf – лист:

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

- визначає поведінку примітивних об’єктів у композиції.

3. Composite – складовий об’єкт:

- визначає поведінку компонентів, у яких є нащадки;

- зберігає компоненти-нащадки;

- реалізує операції, що відносяться до управління нащадками в інтерфейсі класу Component.

4. Client –клієнт:

- маніпулює об’єктами композиції через інтерфейс Component.

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

Результати використання. Паттерн Компонувальник [12]:

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

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

3. Полегшує додавання нових видів компонентів. Нові підкласи класів Composite або Leaf будуть автоматично працювати з вже існуючими структурами і клієнтським кодом. Змінювати клієнта при додаванні нових компонентів не потрібно.

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

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

Паттерн Фасад (Faсade)

Призначення. Паттерн Фасад – це структурний паттерн, який теж змінює інтерфейс, як і Адаптер але з іншої причини: для його спрощення. Паттерн приховує всі складності внутрішньої будови одного або декількох класів за лаконічним, чітко визначеним фасадом.Надає уніфікований інтерфейс замість набору інтерфейсів деякої підсистеми. Фасад визначає інтерфейс більш високого рівня, який спрощує використання підсистеми. В основному цей шаблон використовується в тих випадках, коли необхідний новий спосіб взаємодії із системою – більш простої в порівнянні з вже існуючим. Крім того, він може застосовуватися, коли потрібно використовувати систему деяким специфічним чином – наприклад, звертатися до програми тривимірної графіки для побудови двомірних зображень [14,17].

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

Мотивація застосування. Паттерн Фасад використовується, коли:

- необхідно надати простий інтерфейс до складної підсистеми. Часто підсистеми ускладнюються по мірі розвитку. Застосування більшості паттернів призводить до появи менших класів, але в більшій кількості. Таку підсистему простіше використовувати і налаштовувати під конкретні потреби, але разом з тим застосовувати підсистему без налагодження стає важче. Фасад пропонує певний вид системи за замовчуванням, влаштовує більшість клієнтів. І лише ті об’єкти, яким потрібні більш широкі можливості налагодження, можуть звернутися безпосередньо до того, що знаходиться за фасадом;

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

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

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

- шаблон Facade також може використовуватися для приховання або інкапсуляції базової системи. У цьому випадку клас Facade включає основну систему як свій закритий член. Тому основна система буде взаємодіяти тільки з класом Facade, залишаючись недоступною і невидимою для всіх інших користувачів. Мається декілька причин для інкапсуляції основної системи, а саме:

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

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

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