引言

為子系統中的一組介面提供一個一致的介面，此模式定義了一個高層介面，這個介面是的這一子系統更加容易使用

結構圖

角色

外觀（Façade）角色

• 客戶端呼叫這個角色的方法。該角色知道相關的一個或多個子系統的功能和責任，該角色會將從客戶端發來的請求委派帶相應的子系統中去。

子系統（SubSystem）角色

• 一個類的集合。每個子系統都可以被客戶端直接呼叫或被外觀角色呼叫。對於子系統而言，外觀僅僅是另外一個客戶端，子系統並不知道外觀的存在。

內容

使用了外觀模式之後，客戶端只依賴與外觀類，從而將客戶端與子系統的依賴解耦了，如果子系統發生改變，此時客戶端的程式碼並不需要去改變。

外觀模式的實現核心
 

• 由外觀類去儲存各個子系統的引用，實現由一個統一的外觀類去包裝多個子系統類，然而客戶端只需要引用這個外觀類，然後由外觀類來呼叫各個子系統中的方法，然而這樣的實現方式非常類似介面卡模式

外觀模式與介面卡模式不同的是

• 介面卡模式是將一個物件包裝起來以改變其介面，而外觀是將一群物件 ”包裝“起來以簡化其介面。它們的意圖是不一樣的，介面卡是將介面轉換為不同介面，而外觀模式是提供一個統一的介面來簡化介面。

應用場景

設計初期，需有意識去分層（敲過的三層和七層中，就在業務邏輯層和表示層之間建立了Façade，使得耦合性大大降低）

開發階段，子系統往往因不斷重構演化變得越來越複雜，增加Façade，減少了它們之間的依賴

維護遺留大型系統，讓新系統與Façade物件互動，Façade與遺留程式碼互動，即可分成兩部分，減少維護的困難

感想

在機房合作中，外觀的意義尤為顯著，我們組的分工為：G:UI層 ， D:Façade層+BLL層+Factory層， Z:IDAL層+DAL層 ，G 需要什麼方法，直接就呼叫D寫在Façade中的方法，完全不需要考慮後面的任何細節，深刻體會到解耦的美麗。