Эта статья создана как продолжение описания серии простых паттернов и представляет структурный паттерн под названием Фасад, который решает проблему использования набора интерфейсов в некоторой конкретной системе, предоставляя интерфейс более высокого уровня.
Шаблоны создания:
Структурные образцы:
Фасад (эта статья)
Поведенческие модели:
Основная суть
Паттерн Фасад полезен в случаях, когда несколько подсистем имеют интерфейсы, в которых отсутствуют общие места, но необходимо обеспечить простой интерфейс.
По мере развития приложения включенные подсистемы становятся меньше, их можно использовать повторно и настраивать. Но таким образом клиентам становится сложнее их использовать, особенно когда нет необходимости настраивать такие подсистемы.
Паттерн Фасад предоставляет простой интерфейс по умолчанию, которого достаточно для большинства клиентов. Для тех, кому нужна дополнительная функциональность и настраиваемость, есть возможность смотреть дальше фасада.
Этот шаблон также помогает отделить клиентов от классов с помощью жесткой реализации абстракции. Таким образом, клиенты будут работать только с простыми и понятными интерфейсами, которые представляют только необходимые и предсказуемые функции.
Этот паттерн включает в себя две основные роли:
- Фасад - делегирует вызов определенному классу подсистемы.
- Подсистема - отдельный класс юнита, отвечающий за конкретную функциональность
Пример использования
Давайте создадим кофемашину с некоторыми реализованными внутри нее методами, например TurnOn, TurnOff, startHeating, brewCoffee, cleanMachine. Для конечного пользователя нет необходимости делать все необходимое, потому что производитель кофемашины может сделать удобные кнопки на верхней части кофемашины, а удобные программы - под капотом. Нравится: makeCoffee и cleanMachine. Такая верхняя часть кофемашины носит название Фасад. Таким образом, пользователь может просто нажать одну кнопку, и кофемашина пройдет весь жизненный цикл.
Выгода
Паттерн Фасад избавляет клиентов от взаимодействия с распределенными и сложными классами подсистем за счет агрегированного компонента фасада с хорошо известным и документированным API.
Использование этого шаблона позволяет изменять компоненты подсистемы и, следовательно, уменьшать связь между клиентом и компонентами. Это может помочь сэкономить время на перекомпиляцию в случае изменения подклассов (например, при горячей замене).
Еще одно преимущество использования паттерна фасада заключается в том, что он не запрещает клиентам напрямую использовать классы подсистем, если они вынуждены.
Использование этого шаблона помогает сократить объем пользовательской документации, поскольку для пользователя жизненно важно знать, как использовать Facade API, и не нужно глубоко погружаться в реализацию подсистемы.
Слабые места
Использование этих шаблонов приводит к созданию дополнительного класса (Фасада), что может быть лишним и бесполезным усилием, особенно в случаях, когда от системы не ожидается большой сложности. Настоящая выгода может быть получена только в больших и сложных системах с большим деревом подсистем.
Вывод
Паттерн Фасад можно использовать с паттерном Абстрактная фабрика (или даже вместо него). Это помогает скрыть от клиента классы, специфичные для платформы.
Также узор Посредник похож на Фасад. Он абстрагирует клиента от существующих классов. Но обычно цель посредника - абстрагировать связь между подклассами и часто централизовать функциональность, которая не принадлежит ни одному из них.
Для взаимодействия с клиентом нет необходимости иметь много объектов Facade. Так что часто это Синглтоны.
Если вы нашли эту статью полезной, нажмите кнопку 👏 и оставьте комментарий ниже!
