立面是指建筑物的外觀。 當穿過街道時，我們所看到的只是建筑物的外觀。 該圖面抽象了建筑物的所有復雜實施細節。

同樣， 外觀設計模式旨在為子系統中的一組接口提供統一的接口。 這個統一的接口對客戶端隱藏了子系統的復雜性。 它屬于結構模式類別。

Java中的java.util.Connection是外觀，因為它允許我們創建數據庫連接并隱藏實現細節。 同樣， java.net。 URL類是另一個外觀，它公開了隱藏所有涉及細節的openStream（）方法。

外觀模式通常是重構模式。 對于大型的復雜子系統，使用外觀模式并為客戶端提供友好的界面進行交互是一個相當不錯的主意。

實施外觀模式：

讓我們首先定義一個接口– BookGenre ：

public interface BookGenre { List<Book> getBookList(); }

代表不同書籍類別的所有類都將實現此接口：

public class Fiction implements BookGenre { ... } ? public class NonFiction implements BookGenre { ... } ? public class Technology implements BookGenre { ... }

我們可以讓客戶自己與所有子系統類進行交互，以借用一本書。

但是為了簡化起見，讓我們創建一個LibraryService作為外觀，它將公開以下功能：

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 ); } ?... }

為了使實現簡單，我們在此假設每個書名只有一本書。

請注意，我們尚未添加任何其他功能。 方法借書（）使用現有的子系統API來執行此操作。

UML圖：

我們可以將上面的示例表示為：

有了這個外觀，我們的客戶就可以直接與其交互，而不必自己處理系統內部細節。

值得注意的要點：

讓我們快速回顧一些要點：

• 充當子系統的入口點，并且不向子系統添加更多功能
• 隱藏在門面類后面的子系統的復雜性； 簡化了客戶端的訪問點
• 消除了客戶端類自行管理子系統的需要
• 促進客戶端和子系統之間的松散耦合
• 外觀類絕不限制客戶對子系統的直接訪問
• 我們可以根據需要為復雜系統創建任意數量的外觀。 這樣做的目的是使客戶端易于訪問
• 努力維護額外的代碼層并將其與我們的子系統進行的更改同步

結論：

在本教程中，我們探索了另一種稱為外觀模式的結構設計模式。 這是一種重構模式，主要用于為復雜且設計不良的子系統提供更簡單的外觀。

翻譯自: https://www.javacodegeeks.com/2019/08/facade-design-pattern-java.html

總結

以上是生活随笔為你收集整理的Java中的外观设计模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。