При поиске подходящих стратегий для упрощения сложного программного обеспечения неизбежно сталкиваешься с паттерном проектирования фасада или просто паттерном фасада. Подобно паттерну декоратора или композитному паттерну, он относится к категории структурных паттернов так называемых паттернов проектирования GoF (аббревиатура «GoF» означает «Gang of Four»), которые оказали решающее влияние на проектирование программного обеспечения с момента публикации в 1994 году.
В этой статье мы расскажем вам, что такое паттерн фасада и как он помогает разработчикам выравнивать подсистемы.
Что такое паттерн фасад
Шаблон проектирования фасада является одним из 23 шаблонов проектирования GoF, которые были опубликованы в 1994 году авторами Эрихом Гаммой, Ральфом Джонсоном, Ричардом Хелмом и Джоном Влиссидесом в книге «Design Patterns: Elements of Reusable Object-Oriented Software» в качестве руководства для разработчиков программного обеспечения. В целом, эти паттерны направлены на упрощение создания гибкого, многократно используемого программного обеспечения. Паттерн фасада определяет пример решения для простого объединения различных интерфейсов в сложных системах. Универсальный класс фасада, который также выполняет функции интерфейса, делегирует важные функциональные возможности программного обеспечения соответствующим подсистемам, чтобы максимально упростить работу с различными подкомпонентами программы.
Какие проблемы решает паттерн фасада?
Клиенты, обращающиеся к сложной подсистеме, напрямую обращаются к большому количеству объектов с совершенно разными интерфейсами или зависят от этих объектов. Это делает реализацию, адаптацию, тестирование и повторное использование клиентов особенно сложными для разработчиков. Именно здесь может быть полезен шаблон проектирования фасада.
Шаблон проектирования фасада определяет центральный объект фасада, который:
- реализует универсальный интерфейс для различных интерфейсов подсистемы (подсистем).
- и (при необходимости) может выполнять дополнительные функции до или после пересылки клиентского запроса.
Как посредник, фасадный объект обеспечивает упрощение доступа и связи с отдельными компонентами подсистемы и минимизацию прямой зависимости от этих компонентов. Он делегирует клиентские вызовы, поэтому клиентам не нужно знать классы, их связи и зависимости.
В целях защиты вашей конфиденциальности видео не будет загружаться, пока вы не нажмете на него.
Паттерн Facade: UML диаграмма классов паттерна проектирования
Фасад или класс фасада является решающей структурирующей единицей паттерна фасада. Другими словами, его реализация и подготовка являются основополагающей задачей для разработчиков, желающих упростить свое сложное программное обеспечение с помощью этого удобного паттерна проектирования. После реализации клиентские объекты взаимодействуют с фасадным классом, который в этой новой системе является единственным экземпляром, от которого напрямую зависят клиенты.
Следующая диаграмма UML иллюстрирует взаимодействие клиентов, фасада и подсистемных классов в соответствии с паттерном фасада.
Модель фасада: преимущества и недостатки
Преимущества паттерна проектирования фасада очевидны: фасад «скрывает» лежащие в его основе программные подсистемы и тем самым снижает сложность этих систем. Кроме того, этот подход способствует реализации принципа свободной связи. Благодаря низкой степени взаимозависимости отдельных компонентов, изменения (модификации, сопровождение) удобны и возможны в любое время. Из-за свободной связи подсистему легче расширять.
Если клиентам необходим прямой доступ к определенным классам подсистемы, это также может быть обеспечено в модели фасадного паттерна. В этом случае необходимо запрограммировать только видимость подсистемы, чтобы клиент при необходимости мог обойти фасад.
Однако использование модели проектирования фасада имеет некоторые недостатки. Из-за своей центральной роли реализация фасада является утомительной и сложной задачей, особенно если его приходится вставлять в существующий код. Как правило, установка фасадного интерфейса требует дополнительной стадии перенаправления, что в свою очередь увеличивает время вычислений для вызовов методов и функций, доступа к памяти и т. д. Наконец, фасадный паттерн также таит в себе риск того, что программное обеспечение станет слишком зависимым от центрального главного интерфейса.
| Преимущества | Недостатки |
|---|---|
| Минимизирует сложность подсистем | Сложная реализация (особенно с существующим кодом) |
| Способствует принципу свободной связи | Подход связан с дополнительным уровнем непрямолинейности |
| Программное обеспечение становится более гибким и легко расширяемым | Высокая степень зависимости на интерфейсе фасада |
Типичные случаи использования паттерна проектирования фасада
Свойства конструкции фасада делают его интересным шаблоном для нескольких сценариев применения. Прежде всего, существует желание иметь единый интерфейс для доступа к сложным подсистемам или любому количеству объектов. Фасад обещает упростить ситуацию. Вот почему использование стратегии паттерна фасада должно играть важную роль при планировании проекта.
Другим типичным применением является программное обеспечение, в котором необходимо минимизировать зависимость между клиентами и базовыми подсистемами.
Наконец, паттерн фасада — это полезный подход к планированию проектов программного обеспечения, которые имеют несколько слоев. Фасады выступают в качестве коммуникационных интерфейсов между отдельными слоями, повышая гибкость и возможность расширения и адаптации компонентов.
Практический пример реализации паттерна «Фасад
Паттерн проектирования фасадов связан с конкретными языками программирования. Обычно паттерн используется в C++, C#, JavaScript, Java, PHP и Python. Следующий пример паттерна фасада основан на Java и взят с сайта tutorialspoint.com.
В этом примере универсально применимый интерфейс «Shape» должен быть определен для объектов, представляющих геометрическую форму. Кроме того, создаются конкретные классы, реализующие интерфейс, а также фасадные классы под названием «ShapeMaker», которые отвечают за делегирование клиентских запросов.
Во-первых, мы создаем интерфейс Shape.java, используя следующий код:
public interface Shape {
void draw();
}Во-вторых, создаются три конкретных класса, которые реализуют интерфейс: Rectangle.java (класс для прямоугольных объектов), Square.java (класс для квадратных объектов) и Circle.java (класс для круглых объектов).
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}public class Square implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}Наконец, в код интегрируется фасадный классShapeMaker, к которому будут обращаться клиенты для создания различных фигур:
public class ShapeMaker {
private Shape circle;
private Shape rectangle;
private Shape square;
public ShapeMaker() {
circle = new Circle();
rectangle = new Rectangle();
square = new Square();
}
public void drawCircle(){
circle.draw();
}
public void drawRectangle(){
rectangle.draw();
}
public void drawSquare(){
square.draw();
}
}