Фасад означает лицо здания. Проходя через улицу, все, на что мы смотрим, — это лицо здания. Лицо абстрагирует все сложные детали реализации здания.
Точно так же шаблон проектирования фасада стремится предоставить унифицированный интерфейс для набора интерфейсов в подсистеме. Этот унифицированный интерфейс скрывает сложность подсистемы от клиента. Он подпадает под категорию структурных моделей.
Java.util.Connection в Java — это фасад, поскольку он позволяет нам создавать соединения с БД и скрывает детали реализации. Точно так же, java.net. Класс URL — это еще один фасад, который предоставляет метод openStream (), скрывающий все вовлеченные детали.
Фасадный рисунок обычно представляет собой рефакторинговый рисунок. Для большой сложной подсистемы довольно неплохо использовать шаблон фасада и предоставлять клиентам дружественный интерфейс для взаимодействия.
Реализация шаблона фасада:
Давайте начнем с определения интерфейса — BookGenre :
|
1
2
3
|
public interface BookGenre { List<Book> getBookList();} |
Все классы, представляющие разные категории книг, будут реализовывать этот интерфейс:
|
01
02
03
04
05
06
07
08
09
10
11
|
public class Fiction implements BookGenre { ...} public class NonFiction implements BookGenre { ...} public class Technology implements BookGenre { ... } |
Мы можем позволить нашему клиенту самостоятельно взаимодействовать со всеми классами подсистем, чтобы одолжить книгу.
Но чтобы упростить ситуацию, давайте создадим LibraryService в качестве фасада, который будет предоставлять такие функции:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
public enum BookType { FICTION, NONFICTION, TECHNOLOGY } public class LibraryService { private BookGenre fiction; private BookGenre nonFiction; private BookGenre technology; public LibraryService() { this.fiction = new Fiction(); this.nonFiction = new NonFiction(); this.technology = new Technology(); } public void borrowBook(BookType type, String name) { List<Book> books; switch(type) { case FICTION: books = this.fiction.getBookList(); break; case NONFICTION: books = this.nonFiction.getBookList(); break; default: books = this.technology.getBookList(); } Book book = BookService.findBookByName(books, name); book.setAvailability(false); } ...} |
Для простоты реализации мы предположили, что для каждого названия книги доступна только одна книга.
Обратите внимание, что мы не добавили никакой дополнительной функциональности. Метод loanBook () использует существующие API подсистем для выполнения этой операции.
Диаграмма UML:
Мы можем представить приведенный выше пример как:
С этим фасадом наш клиент может напрямую взаимодействовать с ним и избегать самостоятельной работы с внутренними деталями системы.
Интересные моменты:
Давайте быстро напомним несколько важных моментов:
- Действует как точка входа в подсистему и не добавляет больше функциональности подсистеме.
- Скрывает сложность подсистемы за классом фасада; упрощает точку доступа для клиента
- Устраняет необходимость того, чтобы клиентский класс управлял подсистемой самостоятельно
- Способствует слабой связи между клиентом и подсистемой
- Класс Facade никоим образом не ограничивает прямой доступ клиента к подсистеме
- Мы можем создать столько фасадов, сколько необходимо для сложной системы. Идея состоит в том, чтобы облегчить доступ для клиента
- Добавляет усилия по поддержанию дополнительного уровня кода и его синхронизации с изменениями, которые претерпевает наша подсистема
Вывод:
В этом уроке мы рассмотрели еще один шаблон структурного проектирования, известный как шаблон фасада. Это шаблон рефакторинга, который в основном используется для упрощения работы со сложной плохо спроектированной подсистемой.
|
Опубликовано на Java Code Geeks с разрешения Шубхры Шриваставы, партнера нашей программы JCG . Смотрите оригинальную статью здесь: Шаблон дизайна фасада в Java Мнения, высказанные участниками Java Code Geeks, являются их собственными. |