Патерн фасад. 
Патерн фасад

Шаблон фасад (англ. Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.

Фасад — паттерн, структурирующий объекты, предоставляя ко всем ним доступ через единый шлюз.

Назначение паттерна Facade.

• -Паттерн Facade предоставляет унифицированный интерфейс вместо набора интерфейсов некоторой подсистемы. Facade определяет интерфейс более высокого уровня, упрощающий использование подсистемы.
• — Паттерн Facade «обертывает» сложную подсистему более простым интерфейсом. проектирование шаблон унифицированный интерфейс

" Разбиение на подсистемы облегчает проектирование сложной системы в целом. Общая цель всякого проектирования — свести к минимуму зависимость подсистем друг от друга, а также обмен информацией между ними. Один из способов решения этой задачи — введение общего объекта фасад, предоставляющий единый упрощенный интерфейс к более сложным системным средствам. Можно также сказать, что тем самым мы более приближаемся к построению системы по принципу «черного ящика»: единый интерфейс целой большой системы начинает выступать как интерфейс «черного ящика» и мы не должны знать, как он устроен, какие внутри него взаимосвязи других объектов, сколько их вообще и т. д. Мы просто используем его в соответствии с его интерфейсом, задавая на вход определенные данные и получая соответствующие результаты. «Клиенты хотят получить упрощенный интерфейс к общей функциональности сложной подсистемы.

Вопрос как обеспечить унифицированный интерфейс с набором разрозненных реализаций или интерфейсов, например, с подсистемой, если нежелательно высокое связывание с этой подсистемой или реализация подсистемы может измениться?

Это решается следующим образом Определяется одна точка взаимодействия с подсистемой — фасадный объект, обеспечивающий общий интерфейс с подсистемой, и возложить на него обязанность по взаимодействию с её компонентами. Фасад — это внешний объект, обеспечивающий единственную точку входа для служб подсистемы. Реализация других компонентов подсистемы закрыта и не видна внешним компонентам. Фасадный объект обеспечивает реализацию GRASP паттерна Устойчивый к изменениям (Protected Variations) с точки зрения защиты от изменений в реализации подсистемы.

Используется паттерн фасад.

1. Когда хотят предоставить простой интерфейс к сложной подсистеме.

Часто подсистемы усложняются по мере развития. Применение большинства паттернов приводит к появлению меньших классов, но в большем количестве. Такую подсистему проще повторно использовать и настраивать под конкретные нужды, но вместе с тем применять подсистему без настройки становится труднее. Фасад предлагает некоторый вид системы по умолчанию, устраивающий большинство клиентов. И лишь те объекты, которым нужны более широкие возможности настройки, могут обратиться напрямую к тому, что находится за фасадом.

2. Когда между клиентами и классами реализации абстракции существует много зависимостей.

Фасад позволит изолировать подсистему как от клиентов, так и от других подсистем, что, в свою очередь, способствует повышению степени независимости и переносимости;

И когда хотят разложить подсистему на отдельные слои: расслоить.

Используют фасад для определения точки входа на каждый уровень подсистемы. Если подсистемы зависят друг от друга, то зависимость можно упростить, разрешив подсистемам обмениваться информацией только через фасады.

Структура паттерна Facade.

Клиенты общаются с подсистемой через Facade. При получении запроса от клиента объект Facade переадресует его нужному компоненту подсистемы. Для клиентов компоненты подсистемы остаются «тайной, покрытой мраком» .

UML-диаграмма классов паттерна Facade.

Подсистемы SubsystemOne и SubsystemThree не взаимодействуют напрямую с внутренними компонентами подсистемы SubsystemTwo. Они используют «фасад» SubsystemTwoWrapper (т.е. абстракцию более высокого уровня).

Участниками паттерна Фасад (Facade) являются.

1. Facade (Compiler) — фасад.

Осведомлен о том, каким классам подсистемы адресовать запрос.

Делегирует запросы клиентов подходящим объектам внутри подсистемы.

2. Классы подсистемы (Scanner, Parser, ProgramNode и т. д.).

Реализуют функциональность подсистемы.

Выполняют работу, запрошенную объектом Facade, которую в свою очередь запросил у Facade-а один из клиентов.

Ничего не «знают» о существовании самого фасада, то есть не хранят ссылок на него.

Схема использования паттерна Фасад (Facade).

Клиенты общаются с подсистемой, посылая запросы фасаду. Он переадресует их подходящим объектам внутри подсистемы. Хотя основную работу выполняют именно объекты подсистемы, фасаду, возможно, придется преобразовать свой интерфейс в интерфейсы подсистемы.

Клиенты, пользующиеся фасадом, не имеют прямого доступа к объектам подсистемы.

Вопросы, касающиеся реализации паттерна Фасад (Facade).

При реализации фасада следует обратить внимание на следующие вопросы: Уменьшение степени связанности клиента с подсистемой.

Степень связанности можно значительно уменьшить, если сделать класс Facade абстрактным. Его конкретные подклассы будут соответствовать различным реализациям подсистемы. Тогда клиенты смогут взаимодействовать с подсистемой через интерфейс абстрактного класса Facade. Это изолирует клиентов от информации о том, какая реализация подсистемы используется.

Вместо порождения подклассов можно просто конфигурировать объект Facade различными объектами подсистем — передавать ему на начальном этапе (создании) соответствующие объекты. Для настройки фасада достаточно будет заменить потом один или несколько таких объектов, группу взаимосвязанных объектов и т. д.

Открытые и закрытые классы подсистем.

Подсистема похожа на класс в том отношении, что у обоих есть интерфейсы и оба что-то инкапсулируют. Класс — инкапсулирует состояние и операции, а подсистема — классы. И если полезно различать открытый и закрытый интерфейсы класса, то не менее разумно говорить об открытом и закрытом интерфейсах подсистемы.

Открытый интерфейс подсистемы состоит из классов, к которым имеют доступ все клиенты; закрытый же интерфейс доступен только для расширения подсистемы. Класс Facade, конечно же, является частью открытого интерфейса, но это не единственная часть. Другие классы подсистемы также могут быть открытыми. Например, в системе компиляции классы Parser и Scanner — часть открытого интерфейса.

Делать классы подсистемы закрытыми иногда полезно, но это поддерживается немногими объектно-ориентированными языками. Например, и в C++, и в Smalltalk для классов традиционно использовалось глобальное пространство имен. Однако комитет по стандартизации C++ добавил к языку пространства имен, и это позволило разрешать доступ только к открытым классам подсистемы.

У паттерна фасад есть следующие преимущества и недостатки:

1. Изолирует клиентов от компонентов подсистемы Уменьшая тем самым число объектов, с которыми клиентам приходится иметь дело, упрощая работу с подсистемой.

2. Позволяет ослабить связанность между подсистемой и ее клиентами.

Зачастую компоненты подсистемы сильно связаны: многие классы из разных частей и слоев системы взаимодействуют с друг другом, меняя один такой класс, приходится перекомпилировать и остальные связанные и т. д. Слабая связанность позволяет видоизменять компоненты, не затрагивая при этом клиентов. Фасады помогают разложить систему на слои и структурировать зависимости между объектами, а также избежать сложных и циклических зависимостей. Это оказывается важным, если клиент и подсистема реализуются независимо.

Уменьшение числа зависимостей на стадии компиляции чрезвычайно важно в больших системах. Хочется, конечно, чтобы время, уходящее на перекомпиляцию после изменения классов подсистемы, было минимальным. Сокращение числа зависимостей за счет фасадов может уменьшить количество нуждающихся в повторной компиляции файлов после небольшой модификации какой-нибудь важной подсистемы. Фасад может также упростить процесс переноса системы на другие платформы, поскольку уменьшается вероятность того, что в результате изменения одной подсистемы понадобится изменять и все остальные.

3. Фасад не исключает возможности приложениям напрямую обращаться к классам подсистемы, если это необходимо.

Таким образом, у вас есть выбор между простотой и общностью. Совет конечно очевидный: как можно только в крайних случаях прибегайте к прямому взаимодействию с классом за фасадом, лучше если возможно все же как-нибудь обобщить/абстрагировать эту операцию и добавить ее в сам фасад.

4. С другой стороны, если фасад является единственной точкой доступа к подсистеме, то он будет ограничивать возможности, которые могут понадобиться «продвинутым» пользователям.

5. Объект Facade, реализующий функции посредника, должен оставаться довольно простым и не быть всезнающим «оракулом» .

Пример паттерна Facade.

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

.

При использовании паттерна Facade необходимо Определить для подсистемы простой, унифицированный интерфейс.

Спроектировать класс «обертку», инкапсулирующий подсистему.

Вся сложность подсистемы и взаимодействие ее компонентов скрыты от клиентов. «Фасад» / «обертка» переадресует пользовательские запросы подходящим методам подсистемы.

Клиент использует только «фасад» .

Рассмотрить вопрос о целесообразности создания дополнительных «фасадов» .

Особенности паттерна Facade.

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

Если Flyweight показывает, как сделать множество небольших объектов, то Facade показывает, как сделать один объект, представляющий целую подсистему.

Mediator похож на Facade тем, что абстрагирует функциональность существующих классов. Однако Mediator централизует функциональность между объектами-коллегами, не присущую ни одному из них. Коллеги обмениваются информацией друг с другом через Mediator. С другой стороны, Facade определяет простой интерфейс к подсистеме, не добавляет новой функциональности и не известен классам подсистемы.

Abstract Factory может применяться как альтернатива Facade для сокрытия платформенно-зависимых классов.

Объекты «фасадов» часто являются Singleton, потому что требуется только один объект Facade.

Adapter и Facade в являются «обертками», однако эти «обертки» разных типов. Цель Facade — создание более простого интерфейса, цель Adapter — адаптация существующего интерфейса. Facade обычно «обертывает» несколько объектов, Adapter «обертывает» один объект.

Пример использования.

Разбиение системы на компоненты позволяет снизить ее сложность. Ослабить связи между компонентами системы можно с помощью паттерна Facade. Объект «фасад» предоставляет единый упрощенный интерфейс к компонентам системы.

В примере ниже моделируется система сетевого обслуживания. Фасад FacilitiesFacade скрывает внутреннюю структуру системы. Пользователь, сделав однажды запрос на обслуживание, затем 1−2 раза в неделю в течение 5 месяцев справляется о ходе выполнения работ до тех пор, пока его запрос не будет полностью обслужен.