說明：設計模式系列文章是讀劉偉所著《設計模式的藝術之道(軟體開發人員內功修煉之道)》一書的閱讀筆記。個人感覺這本書講的不錯，有興趣推薦讀一讀。詳細內容也可以看看此書作者的部落格https://blog.csdn.net/LoveLion/article/details/17517213
模式概述
絕大多數B/S系統都有一個首頁或者導航頁面，大部分C/S系統都提供了選單或者工具欄，在這裡，首頁和導航頁面就充當了B/S系統的外觀角色，而選單和工具欄充當了C/S系統的外觀角色，通過它們使用者可以快速訪問子系統，增強了軟體的易用性。
在軟體開發中，有時候為了完成一項較為複雜的功能，一個客戶類需要和多個業務類互動，而這些需要互動的業務類經常會作為一個整體出現，由於涉及到的類比較多，導致使用時程式碼較為複雜，此時，特別需要一個類似服務員一樣的角色，由它來負責和多個業務類進行互動，而客戶類只需與該類互動。外觀模式通過引入一個外觀角色(Facade)來簡化客戶端與子系統(Subsystem)之間的互動，為複雜的子系統呼叫提供一個統一的入口，降低子系統與客戶端的耦合度，使得客戶端呼叫非常方便。
模式定義
外觀模式中，一個子系統的外部與其內部的通訊通過一個統一的外觀類進行，外觀類將客戶類與子系統的內部複雜性分隔開，使得客戶類只需要與外觀角色打交道，而不需要與子系統內部的很多物件打交道。
外觀模式(
Facade Pattern)：為子系統中的一組介面提供一個統一的入口。外觀模式定義了一個高層介面，這個介面使得這一子系統更加容易使用
外觀模式又稱為門面模式，它是一種物件結構型模式。外觀模式是迪米特法則的一種具體實現，通過引入一個新的外觀角色可以降低原有系統的複雜度，同時降低客戶類與子系統的耦合度。
模式結構圖
外觀模式沒有一個一般化的類圖描述，下圖所示的類圖也可以作為描述外觀模式的結構圖：
外觀模式包含如下兩個角色：
-
Facade（外觀角色）：在客戶端可以呼叫它的方法，在外觀角色中可以知道相關的（一個或者多個）子系統的功能和責任；在正常情況下，它將所有從客戶端發來的請求委派到相應的子系統去，傳遞給相應的子系統物件處理。
-
SubSystem（子系統角色）：在軟體系統中可以有一個或者多個子系統角色，每一個子系統可以不是一個單獨的類，而是一個類的集合，它實現子系統的功能；每一個子系統都可以被客戶端直接呼叫，或者被外觀角色呼叫，它處理由外觀類傳過來的請求；子系統並不知道外觀的存在，對於子系統而言，外觀角色僅僅是另外一個客戶端而已。
模式虛擬碼
外觀模式中所指的子系統是一個廣義的概念，它可以是一個類、一個功能模組、系統的一個組成部分或者一個完整的系統。子系統類通常是一些業務類，實現了一些具體的、獨立的業務功能，其典型程式碼如下：
public class SubSystemA {
public void methodA() {
//業務實現程式碼
}
}
public class SubSystemB {
public void methodB() {
//業務實現程式碼
}
}
public class SubSystemC {
public void methodC() {
//業務實現程式碼
}
}
引入外觀類，與子系統業務類之間的互動統一由外觀類來完成
public class Facade {
private SubSystemA obj1 = new SubSystemA();
private SubSystemB obj2 = new SubSystemB();
private SubSystemC obj3 = new SubSystemC();
public void method() {
obj1.methodA();
obj2.methodB();
obj3.methodC();
}
}
由於在外觀類中維持了對子系統物件的引用，客戶端可以通過外觀類來間接呼叫子系統物件的業務方法，而無須與子系統物件直接互動。引入外觀類後，客戶端程式碼變得非常簡單，典型程式碼如下：
public static void main(String[] args) {
Facade facade = new Facade();
facade.method();
}
模式改進
在標準的外觀模式中，如果需要增加、刪除或更換與外觀類互動的子系統類，必須修改外觀類或客戶端的原始碼，這將違背開閉原則，因此可以通過引入抽象外觀類來對系統進行改進，在一定程度上可以解決該問題。在引入抽象外觀類之後，客戶端可以針對抽象外觀類進行程式設計，對於新的業務需求，不需要修改原有外觀類，而對應增加一個新的具體外觀類，由新的具體外觀類來關聯新的子系統物件。
定義抽象外觀類
public abstract class AbstractFacade {
public abstract void method();
}
根據具體的場景，實現具體的外觀類
public class Facade1 extends AbstractFacade {
private SubSystemA obj1 = new SubSystemA();
private SubSystemB obj2 = new SubSystemB();
@Override
public void method() {
obj1.methodA();
obj2.methodB();
}
}
public class Facade2 extends AbstractFacade {
private SubSystemB obj1 = new SubSystemB();
private SubSystemC obj2 = new SubSystemC();
@Override
public void method() {
obj1.methodB();
obj2.methodC();
}
}
客戶端針對抽象外觀類進行程式設計，程式碼片段如下：
public static void main(String[] args) {
AbstractFacade facade = new Facade1();
// facade = new Facade2();
facade.method();
}
模式應用
個人認為外觀模式某些情況下可以看成是對既有系統的再次封裝，所以各種類庫、工具庫(比如hutool)、框架基本都有外觀模式的影子。外觀模式讓呼叫方更加簡潔，不用關心內部的實現，與此同時，也讓越來越多的程式猿多了個調包俠的暱稱(當然了這其中也包括筆者●´ω｀●行無際)。
所以，你可能在很多開原始碼中看到類似XxxBootstrap、XxxContext、XxxMain等類似的Class，再追進去看一眼，你可能發現裡面關聯了一大堆的複雜的物件，這些物件對於外層呼叫者來說幾乎是透明的。
例子太多，以致於不知道舉啥例子(實際是偷懶的藉口O(∩_∩)O哈哈~)。
模式總結
外觀模式並不給系統增加任何新功能，它僅僅是簡化呼叫介面。在幾乎所有的軟體中都能夠找到外觀模式的應用。所有涉及到與多個業務物件互動的場景都可以考慮使用外觀模式進行重構。
主要優點
(1) 它對客戶端遮蔽了子系統元件，減少了客戶端所需處理的物件數目，並使得子系統使用起來更加容易。通過引入外觀模式，客戶端程式碼將變得很簡單，與之關聯的物件也很少。
(2) 它實現了子系統與客戶端之間的鬆耦合關係，這使得子系統的變化不會影響到呼叫它的客戶端，只需要調整外觀類即可。
(3) 一個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀物件。
適用場景
(1) 當要為訪問一系列複雜的子系統提供一個簡單入口時可以使用外觀模式。
(2) 客戶端程式與多個子系統之間存在很大的依賴性。引入外觀類可以將子系統與客戶端解耦，從而提高子系統的獨立性和可移植性。
(3) 在層次化結構中，可以使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯絡，而通過外觀類建立聯絡，降低層之間的耦合度。