外觀模式提供了乙個統一的介面，用來訪問子系統中的一群介面。外觀定義了乙個高層介面，讓子系統更容易使用。
外觀模式不只是簡化了介面，也將客戶從元件的子系統中解耦。
外觀和介面卡可以包裝許多類，但是外觀強調的是簡化介面，而介面卡是為了將介面轉換成不同的介面。
外觀角色（facade）：是模式的核心，他被客戶client角色呼叫，知道各個子系統的功能。同時根據客戶角色已有的需求預訂了幾種功能組合
子系統角色（subsystem classes）：實現子系統的功能，並處理由facade物件指派的任務。對子系統而言，facade和client角色是未知的，沒有facade的任何相關資訊；即沒有指向facade的例項。
客戶角色（client）：呼叫facade角色獲得完成相應的功能。
class在以下情況下可以考慮使用外觀模式：program
}//////
燈光介面
/// public
inte***ce
ilight
//////
燈光介面實現類
/// public
class
light : ilight
public
void
off()
}//////
電視介面
/// public
inte***ce
itv
//////
智慧型家居總開關介面
/// public
inte***ce
ismarthome
public
class
tv : itv
public
void
off()
}public
class
smarthome : ismarthome
public
void
off()
}
(1)設計初期階段，應該有意識的將不同層分離，層與層之間建立外觀模式。
(2) 開發階段，子系統越來越複雜，增加外觀模式提供乙個簡單的呼叫介面。
(3) 維護乙個大型遺留系統的時候，可能這個系統已經非常難以維護和擴充套件，但又包含非常重要的功能，為其開發乙個外觀類，以便新系統與其互動。
優點：
1）對客戶遮蔽子系統元件，減少了客戶處理的物件數目並使得子系統使用起來更加容易。通過引入外觀模式，客戶**將變得很簡單，與之關聯的物件也很少。
2）實現了子系統與客戶之間的松耦合關係，這使得子系統的元件變化不會影響到呼叫它的客戶類，只需要調整外觀類即可。
3）降低了大型軟體系統中的編譯依賴性，並簡化了系統在不同平台之間的移植過程，因為編譯乙個子系統一般不需要編譯所有其他的子系統。乙個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀物件。
4）只是提供了乙個訪問子系統的統一入口，並不影響使用者直接使用子系統類。
缺點：
1） 不能很好地限制客戶使用子系統類，如果對客戶訪問子系統類做太多的限制則減少了可變性和靈活性。
2） 在不引入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或客戶端的源**，違背了「開閉原則」。
乙個系統有多個外觀類：在外觀模式中，通常只需要乙個外觀類，並且此外觀類只有乙個例項，換言之它是乙個單例類。在很多情況下為了節約系統資源，一般將外觀類設計為單例類。當然這並不意味著在整個系統裡只能有乙個外觀類，在乙個系統中可以設計多個外觀類，每個外觀類都負責和一些特定的子系統互動，向使用者提供相應的業務功能。參考：不要試圖通過外觀類為子系統增加新行為：
不要通過繼承乙個外觀類在子系統中加入新的行為，這種做法是錯誤的。外觀模式的用意是為子系統提供乙個集中化和簡化的溝通渠道，而不是向子系統加入新的行為，新的行為的增加應該通過修改原有子系統類或增加新的子系統類來實現，不能通過外觀類來實現。
外觀模式與迪公尺特法則：
外觀模式創造出乙個外觀物件，將客戶端所涉及的屬於乙個子系統的協作夥伴的數量減到最少，使得客戶端與子系統內部的物件的相互作用被外觀物件所取代。外觀類充當了客戶類與子系統類之間的「第三者」，降低了客戶類與子系統類之間的耦合度，外觀模式就是實現**重構以便達到「迪公尺特法則」要求的乙個強有力的**。
抽象外觀類的引入：
外觀模式最大的缺點在於違背了「開閉原則」，
當增加新的子系統或者移除子系統時需要修改外觀類，可以通過引入抽象外觀類在一定程度上解決該問題，客戶端針對抽象外觀類進行程式設計。對於新的業務需求，不修改原有外觀類，而對應增加乙個新的具體外觀類，由新的具體外觀類來關聯新的子系統物件，同時通過修改配置檔案來達到不修改源**並更換外觀類的目的。
歡迎閱讀本系列文章：head first設計模式之目錄
調侃《Head First設計模式》之外觀模式
看下這些元件的類圖 用 實現就是 這時候你應該很煩了 看個電影要開啟這麼多開關真tm煩！而且看完電影後還要把開關都關一遍，甚至聽cd都很麻煩。怎麼辦呢？解決方案很簡單，你需要的只是增加乙個類將各種開關介面包裝起來。如圖hometheate cade類 hometheate cade對外暴露幾個介面，...
headfirst設計模式
花了一周多一點的時間看完了headfirst的設計模式。看完之後有一種恍然大悟的感覺，仔細想想有覺得自己好像什麼也看懂。簡單說下對這本書的一點感悟吧，headfirst的書比較通俗易懂，之前看了四人幫的設計模式，看一半就有一種痛不欲生的感覺，自己水平有限，看不懂，也就沒在勉強自己了。對於模式其實簡單...
HeadFirst 設計模式 工廠模式
定義乙個建立物件的介面，由子類決定要例項化的類。工廠方法將類例項推遲到子類。依賴倒置。第一種方式是 class pizzastore public pizza orderpizza string type class pizzafactory pizza pizza null 將pizza這個例項提...