Page 60 - 4190

створити клас, похідний від Decorator.
8. Підклас Decorator реалізує додаткову функціональність і деле-
гує виконання операції базовому класу Decorator.
9. Клієнт несе відповідальність за конфігурацію системи: встанов-

лює типи і послідовність використання основного об'єкта і декораторів.
Патерн Facade
Патерн Facade (Фасад) – надає уніфікований інтерфейс замість

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

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

ною точкою доступу до підсистеми, то він обмежуватиме можливос-
ті, які можуть знадобитися досвідченим користувачам.
Об'єкт Facade, що реалізовує функції посередника, повинен за-

лишатися досить простим і не бути всезнаючим "оракулом".
Клієнти спілкуються з підсистемою через Facade. При отриманні
запиту від клієнта об'єкт Facade переадресує його потрібному компо-

ненту підсистеми. Для клієнтів компоненти підсистеми залишаються
"таємницею".
UML-діаграма класів патерну Facade зображена на рисунку 6.5.
Підсистеми SubsystemOne і SubsystemThree не взаємодіють без-

посередньо з внутрішніми компонентами підсистеми SubsystemTwo.
Вони використовують "фасад" SubsystemTwoWrapper (тобто абстрак-
цію більш високого рівня).

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

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

60