結構型設計模式外觀模式

我們先來講乙個故事，比如我現在要組裝一台電腦。

方案一：去電子市場買cpu，記憶體條，顯示卡，磁碟等所有用到的部件，然後再進行組裝。但是這個方案的問題在於，要對這些部件有所了解，選擇效能好的，考慮不同部件的相容性問題等。

方案二：自己組裝太麻煩了，找個裝機公司吧，然後說自己的需求，之後就等著拿電腦就完事了。

假設我們把電子市場看成乙個系統，把賣配件的公司看成不同的子系統，那麼客戶端（我）需要完成乙個目標（組裝一台電腦）,需要呼叫乙個系統的多個子系統a，b，c…，需要知道不同子系統的功能，還需要如何組合這個子系統才能完成。

方案二提供了乙個很簡單的方法，能讓客戶端實現相同的功能卻不需要和系統中的多個模組互動。

其實方案二中的裝機公司就是外觀角色，使用者只需要和外觀類互動即可，使用者和子系統的複雜關係交給外觀角色來控制，這就是要講的外觀模式了。

定義：為系統中的一組介面（可以理解為多個子系統）提供了乙個統一的入口。外觀模式提供了乙個高層介面，目的是訪問其他介面可以通過它統一訪問。

表現：乙個子系統外部和其內部的通訊交給外觀類來進行，將客戶類和內部子系統分隔開，客戶類只需要和外觀類交流即可，不需要和內部的很多物件進行交流。

目的：降低了類之間的耦合，降低系統複雜度。

模式結構：

結構圖說明：

facade：外觀角色，客戶可以呼叫它的方法。再外觀角色中知道相關子系統的功能和職責，外觀角色負責將客戶端發來的請求委派到不同的子系統中。

subsystem：子系統角色，系統中存在乙個或多個子系統角色，每乙個子系統都是乙個類集合，實現了特定的功能。

就以開始講的組裝電腦為例子吧。

不同的元件：

class
memory
}class
cpu}

裝機公司：

public
class
buildcompany
}

客戶端測試：

public
class
facaclient
}

很簡單的例子，可以看出了外觀類可以處理客戶端的請求即可。

優點：

缺點：

使用場景：

舉例：網頁中的導航、客戶端中的選單欄等

上面也有講到，如果需要增加、刪除、更換與外觀類直接互動的子系統的化，就必須要修改外觀類或客戶端**類，違背了開閉原則（對擴充套件開發，對修改關閉）。那麼可以引入乙個抽象外觀類來一定程度上解決這個問題。

如果有新的業務需求，不需要修改原有的外觀類，只要增加新的具體外觀類，又新的具體外觀類來關聯新的子系統物件，通過修改配置檔案就可以做到不更改源**來更換外觀類的目的。

擴充套件的結構圖：

總體來說，外觀模式還是很好理解的，目的就是減少耦合和系統複雜程度。生活中也經常可以遇到外觀模式的一些思想體現，大家可以留心觀察一下。

結構型設計模式 外觀模式