- 1. Цели
- 2. Проблематика
- 3. Обсуждение
- 4. Структура
- 5. Пример
- 6. Контрольный список
- 7. Эмпирические правила
Цели
- Предоставить унифицированный интерфейс для набора интерфейсов в подсистеме. Фасад определяет интерфейс более высокого уровня, который упрощает использование подсистемы.
- Обернуть сложную подсистему более простым интерфейсом.
Проблематика
Для сегмента клиентского доступа требуется упрощенный интерфейс для доступа к общей функциональности сложной подсистемы.
Обсуждение
Фасад испоьлзует инкапсуляцию сложной подсистемы внутри одного интерфейса. Это уменьшает кривую обучения, необходимую для успешного использования подсистемы. Это также способствует отвязыванию подсистемы от потенциально многих клиентов. С другой стороны, если Facade является единственной точкой доступа для подсистемы, это ограничит возможности и гибкость, которые могут потребоваться «опытным пользователям».
Объект Facade должен быть довольно простым посредником. Он не должен становиться всезнающим оракулом или «божественным» объектом.
Структура
Фасад принимает в себя «загадку, завернутую в загадку, окутанную тайной», и добавляет оболочку, которая приручает аморфную и непостижимую массу программного обеспечения для предоставления простого и понятного клиентского интерфейса.
SubsystemOne и SubsystemThree не взаимодействуют с внутренними компонентами SubsystemTwo. Они используют «фасад» SubsystemTwoWrapper (т. е. Абстракция более высокого уровня).
Пример
Фасад определяет унифицированный интерфейс более высокого уровня для подсистемы, которая упрощает ее использование. Потребители сталкиваются с фасадом при заказе из каталога. Потребитель звонит на один номер и разговаривает с представителем службы поддержки клиентов. Представитель службы поддержки клиентов выступает в качестве фасада, предоставляя интерфейс отделу исполнения заказов, отделу биллинга и отделу доставки.
Контрольный список
- Определите более простой унифицированный интерфейс для подсистемы или компонента.
- Создайте класс 'wrapper', который инкапсулирует подсистему.
- Фасад/обертка нивелирует сложность и взаимодействие с компонентом, делегируя соответствующие методы.
- Клиент использует (привязан к) только фасад.
- Подумайте, добавит ли фасад дополнительные значения и функционал.
Эмпирические правила
- Фасад определяет новый интерфейс, тогда как Adapter использует старый интерфейс. Помните, что адаптер поддерживает два существующих интерфейса, а не определяет совершенно новый.
- В то время как Flyweight показывает, как сделать много маленьких объектов, Facade показывает, как сделать один объект, представляющий целую подсистему.
- Посредник похож на Facade, поскольку он абстрагирует функциональность существующих классов. Посредник реферирует / централизует произвольные связи между объектами коллег. Напротив, Facade определяет более простой интерфейс для подсистемы, он не добавляет новых функций, и он не известен подсистемам.
- Абстрактную фабрику можно использовать в качестве альтернативы Facade для скрытия классов, специфичных для платформы.
- Объекты фасада часто являются синглтонами, потому что требуется только один объект Facade.
- Адаптер и фасад - оба обертки; но это разные виды оберток. Целью Фасада является создание более простого интерфейса, и целью адаптера является разработка существующего интерфейса. Хотя Facade обычно обертывает несколько объектов, а Adapter обертывает один объект; Фасад мог бы иметь интерфейсный комплекс с одним сложным объектом, а адаптер мог бы обернуть несколько устаревших объектов.