系統的復雜度

　　假設我們需要開發一個坦克模擬系統用于模擬坦克車在各種作戰環境中的行為，其中坦克系統由引擎、控制器、車輪、車身等各子系統構成。

　　如何使用這樣的系統

　　動機（Motivation）

　　上述A方案的問題在于組件的客戶（即外部接口，或客戶程序）和組件中各種復雜的子系統有了過多的耦合，隨著外部客戶程序和各子系統的演化，這種過多的耦合面臨很多變化的挑戰。如何簡化外部客戶程序和系統間的交互接口？如何將外部客戶程序的演化和內部子系統的變化之間的依賴相互解耦？

　　意圖（Intent）

　　為子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《設計模式》GoF

　　例說Facade應用

　　以前面的例子為例

　　我們所說的接口其實并不一定是Interface，只要是Public方法，能被外部調用的方法都叫接口，這里的定義其實是更加廣義的接口定義，即露在外面和外界所交互的這一部分。這里主系統和子系統之間的關系不是繼承關系，而應該是一種包含的關系。

　　這樣在外部使用的時候只能使用TankFacade類和里面的Start、Stop等方法，其他子系統都被包含在內部了。這樣減輕了使用的復雜度，客戶程序只用關心TankFacade，而不用關心里面的子系統情況。更重要的是，這樣的設計有效地把客戶程序和子系統解耦。

　　結構（Structure）

　　這種結構不僅體現了類的單一職責原則，而且也體現了開放封閉原則。而且子系統和系統之間是個組合關系，而不是繼承關系。高層總是相對穩定，低層總是相對易變。所以我們應該盡量依賴高層抽象，而不是低層細節實現。

　　Facade模式的幾個要點

　　從客戶程序的角度來看，Facade模式不僅簡化了整個組件系統的接口，同時對于組件內部與外部客戶程序來說，從某種程度上也達到了一種“解耦”的效果——內部子系統的任何變化不會影響到Facade接口的變化。

Facade設計模式更注重從架構的層次去看整個系統，而不是單個類的層次。Facade很多時候更是一種架構設計模式。

　　注意區分Facade模式、Adapter模式、Bridge模式與Decorator模式：

　　Facade模式注重簡化接口

　　Adapter模式注重轉換接口

　　Bridge模式注重分離接口（抽象）與其實現

　　Decorator模式注重穩定接口的前提下為對象擴展功能

　　.NET架構中的Facade應用

　　假如我們做一個網上購物系統，考慮它的認證系統。用戶權限不同，能做的事情也不同，它可能會調用各種各樣的子系統。認證系統里面也可能包含很多子系統，比如第三方認證等等。這些認證子系統合作起來豐富了我們網站的功能，那么這種情況我們就可以考慮把認證的各個子系統封裝成一個認證系統。

　　如果我們想做跨平臺的及時聊天工具，我們也可以用一個Facade封裝某個平臺系統的API接口。這樣我們在使用API的時候，就不需要去關心平臺內部的變化。