Структурні шаблони проектування - Фасад

шаблоны проектирования

Голи

• Надати уніфікований інтерфейс для набору інтерфейсів у підсистемі. Фасад визначає інтерфейс вищого рівня, який полегшує використання підсистеми.
• Оберти складну підсистему простішим інтерфейсом.

Проблеми

Для сегмента клієнтського доступу потрібен спрощений інтерфейс доступу до загальної функціональності складної підсистеми.

Обговорення

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

Об'єкт Facade має бути досить простим посередником. Він повинен ставати всезнаючим оракулом чи «божественним» об'єктом.

Структура

Фасад бере в себе «загадку, загорнуту в загадку, оповиту таємницею», і додає оболонку, яка приручає аморфну та незбагненну масу програмного забезпечення для надання простого та зрозумілого клієнтського інтерфейсу.

SubsystemOne і SubsystemThree не взаємодіють із внутрішніми компонентами SubsystemTwo. Вони використовують «фасад» SubsystemTwoWrapper (тобто абстракція вищого рівня).

Приклад

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

Контрольний список

1. Визначте простіший уніфікований інтерфейс для підсистеми або компонента.
2. Створіть клас 'wrapper', який інкапсулює підсистему.
3. Фасад/обертання нівелює складність і взаємодію з компонентом, делегуючи відповідні методи.
4. Клієнт використовує (прив'язаний до) лише фасад.
5. Подумайте, чи додасть фасад додаткові значення та функціонал.

Емпіричні правила

• Фасад визначає новий інтерфейс, тоді як Adapter використовує старий інтерфейс. Пам'ятайте, що адаптер підтримує два існуючі інтерфейси, а не визначає абсолютно новий.
• В той час, як Flyweight показує, як зробити багато маленьких об'єктів, Facade показує, як зробити один об'єкт, що представляє цілу підсистему.
• Посередник схожий на Facade, оскільки він абстрагує функціональність існуючих класів. Посередник реферує/централізує довільні зв'язки між об'єктами колег. Навпаки, Facade визначає простіший інтерфейс для підсистеми, він не додає нових функцій, і він не відомий підсистем.
• Абстрактну фабрику можна використовувати як альтернативу Facade для приховання класів, специфічних для платформи.
• Об'єкти фасаду часто є синглтонами, тому що потрібно лише один об'єкт Facade.
• Адаптер і фасад - обидві обгортки; але це різні види обгорток. Метою Фасаду є створення простішого інтерфейсу, і метою адаптера є розробка існуючого інтерфейсу. Хоча Facade зазвичай обгортає кілька об'єктів, а Adapter обгортає один об'єкт; Фасад міг би мати інтерфейсний комплекс із одним складним об'єктом, а адаптер міг би обернути кілька застарілих об'єктів.