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

Условия, Задача, Назначение

1. Хотите предоставить простой интерфейс к сложной подсистеме.
   Часто подсистемы усложняются по мере развития. Применение большинства паттернов приводит к появлению меньших классов, но в большем количестве. Такую подсистему проще повторно использовать и настраивать под конкретные нужды, но вместе с тем применять подсистему без настройки становится труднее. Фасад предлагает некоторый вид системы по умолчанию, устраивающий большинство клиентов. И лишь те объекты, которым нужны более широкие возможности настройки, могут обратиться напрямую к тому, что находится за фасадом;
2. Между клиентами и классами реализации абстракции существует много зависимостей.
   Фасад позволит изолировать подсистему как от клиентов, так и от других подсистем, что, в свою очередь, способствует повышению степени независимости и переносимости;
3. Вы хотите разложить подсистему на отдельные слои: расслоить.
   Используйте фасад для определения точки входа на каждый уровень подсистемы. Если подсистемы зависят друг от друга, то зависимость можно упростить, разрешив подсистемам обмениваться информацией только через фасады.

Решение

Участники паттерна Фасад (Facade)

1. Facade (Compiler) – фасад.
   Осведомлен о том, каким классам подсистемы адресовать запрос.
   Делегирует запросы клиентов подходящим объектам внутри подсистемы.
2. Классы подсистемы (Scanner, Parser, ProgramNode и т.д.).
   Реализуют функциональность подсистемы.
   Выполняют работу, запрошенную объектом Facade, которую в свою очередь запросил у Facade-а один из клиентов.
   Ничего не «знают» о существовании самого фасада, то есть не хранят ссылок на него.

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

1. Уменьшение степени связанности клиента с подсистемой.
   Степень связанности можно значительно уменьшить, если сделать класс Facade абстрактным. Его конкретные подклассы будут соответствовать различным реализациям подсистемы. Тогда клиенты смогут взаимодействовать с подсистемой через интерфейс абстрактного класса Facade. Это изолирует клиентов от информации о том, какая реализация подсистемы используется.
   Вместо порождения подклассов можно просто конфигурировать объект Facade различными объектами подсистем – передавать ему на начальном этапе (создании) соответствующие объекты. Для настройки фасада достаточно будет заменить потом один или несколько таких объектов, группу взаимосвязанных объектов и т.д.
2. Открытые и закрытые классы подсистем.
   Подсистема похожа на класс в том отношении, что у обоих есть интерфейсы и оба что-то инкапсулируют. Класс - инкапсулирует состояние и операции, а подсистема - классы. И если полезно различать открытый и закрытый интерфейсы класса, то не менее разумно говорить об открытом и закрытом интерфейсах подсистемы.
   Открытый интерфейс подсистемы состоит из классов, к которым имеют доступ все клиенты; закрытый же интерфейс доступен только для расширения подсистемы. Класс Facade, конечно же, является частью открытого интерфейса, но это не единственная часть. Другие классы подсистемы также могут быть открытыми. Например, в системе компиляции классы Parser и Scanner - часть открытого интерфейса.
   Делать классы подсистемы закрытыми иногда полезно, но это поддерживается немногими объектно-ориентированными языками. Например, и в C++, и в Smalltalk для классов традиционно использовалось глобальное пространство имен. Однако комитет по стандартизации C++ добавил к языку пространства имен, и это позволило разрешать доступ только к открытым классам подсистемы.

1. Изолирует клиентов от компонентов подсистемы
   Уменьшая тем самым число объектов, с которыми клиентам приходится иметь дело, упрощая работу с подсистемой.
2. Позволяет ослабить связанность между подсистемой и ее клиентами.
   Зачастую компоненты подсистемы сильно связаны: многие классы из разных частей и слоев системы взаимодействуют с друг другом, меняя один такой класс, приходится перекомпилировать и остальные связанные и т.д. Слабая связанность позволяет видоизменять компоненты, не затрагивая при этом клиентов. Фасады помогают разложить систему на слои и структурировать зависимости между объектами, а также избежать сложных и циклических зависимостей. Это оказывается важным, если клиент и подсистема реализуются независимо.
   Уменьшение числа зависимостей на стадии компиляции чрезвычайно важно в больших системах. Хочется, конечно, чтобы время, уходящее на перекомпиляцию после изменения классов подсистемы, было минимальным. Сокращение числа зависимостей за счет фасадов может уменьшить количество нуждающихся в повторной компиляции файлов после небольшой модификации какой-нибудь важной подсистемы. Фасад может также упростить процесс переноса системы на другие платформы, поскольку уменьшается вероятность того, что в результате изменения одной подсистемы понадобится изменять и все остальные.
3. Фасад не исключает возможности приложениям напрямую обращаться к классам подсистемы, если это необходимо. Таким образом, у вас есть выбор между простотой и общностью. Совет конечно очевидный: как можно только в крайних случаях прибегайте к прямому взаимодействию с классом за фасадом, лучше если возможно все же как-нибудь обобщить/абстрагировать эту операцию и добавить ее в сам фасад.

Класс Scanner принимает на входе поток символов и генерирует поток лексем, по одной каждый раз, т.е. он выступает в роли самого первого уровня обработки исходного кода: Scanner.

Далее класс Parser использует класс ProgramNodeBuilder для построения дерева разбора из лексем, возвращенных классом Scanner.

Parser каждый раз вызывает ProgramNodeBuilder для пошагового построения дерева. Взаимодействие этих классов описывается паттерном строитель.

Дерево разбора состоит из экземпляров подклассов класса ProgramNode, таких как StatementNode, ExpressionNode и т.д. Иерархия классов ProgramNode — это пример паттерна компоновщик. Класс ProgramNode определяет интерфейс для манипулирования узлом программы и его потомками, если таковые имеются.

Операция Traverse (обход) принимает объект CodeGenerator (кодогенератор) в качестве параметра. Подклассы ProgramNode используют этот объект для генерации машинного кода в форме объектов Bytecode, которые помещаются в поток BytecodeStream. Класс CodeGenerator описывается паттерном посетитель.

Каждый подкласс ProgramNode реализует операцию Traverse и обращается к ней для обхода своих потомков. Каждый потомок рекурсивно делает то же самое для своих потомков. Например, в подклассе ExpressionNode (узел выражения) операция Traverse определена так: ExpressionNode.

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

1. MemoryObject представляет объекты данных;
2. MemoryObjectCache кэширует данные из объектов MemoryObj ects в физической памяти.
   MemoryObjectCache - это не что иное, как объект Стратегия, в котором локализована политика кэширования;
3. AddressTranslation инкапсулирует особенности оборудования трансляции адресов.

Операция RepairFault вызывается при возникновении ошибки из-за отсутствия страницы. Domain находит объект в памяти по адресу, где произошла ошибка и делегирует операцию RepairFault кэшу, ассоциированному с этим объектом. Поведение объектов Domain можно настроить, заменив их компоненты.