在現實生活中，常常存在辦事較複雜的例子，如辦房產證或註冊一家公司，有時要同多個部門聯絡，這時要是有乙個綜合部門能解決一切手續問題就好了。
軟體設計也是這樣，當乙個系統的功能越來越強，子系統會越來越多，客戶對系統的訪問也變得越來越複雜。這時如果系統內部發生改變，客戶端也要跟著改變，這違背了「開閉原則」，也違背了「迪公尺特法則」，所以有必要為多個子系統提供乙個統一的介面，從而降低系統的耦合度，這就是外觀模式的目標。
外觀（facade）模式又叫作門面模式，是一種通過為多個複雜的子系統提供乙個一致的介面，而使這些子系統更加容易被訪問的模式。該模式對外有乙個統一介面，外部應用程式不用關心內部子系統的具體細節，這樣會大大降低應用程式的複雜度，提高了程式的可維護性。
在日常編碼工作中，我們都在有意無意的大量使用外觀模式。只要是高層模組需要排程多個子系統（2 個以上的類物件），我們都會自覺地建立乙個新的類封裝這些子系統，提供精簡的介面，讓高層模組可以更加容易地間接呼叫這些子系統的功能。尤其是現階段各種第三方 sdk、開源類庫，很大概率都會使用外觀模式。
外觀模式是「迪公尺特法則」的典型應用，它有以下主要優點。
外觀模式的主要缺點如下。
外觀模式的結構比較簡單，主要是定義了乙個高層介面。它包含了對各個子系統的引用，客戶端可以通過它訪問各個子系統的功能。現在來分析其基本結構和實現方法。
外觀模式包含以下主要角色。
其結構圖如下圖所示：
外觀模式的實現**如下：
#include using namespace std;
// 子系統角色1
class subsystem01
};// 子系統角色2
class subsystem02
};// 子系統角色3
class subsystem03
};// 外觀角色
class facade
private:
subsystem01 *obj1 = new subsystem01();
subsystem02 *obj2 = new subsystem02();
subsystem03 *obj3 = new subsystem03();
};int main()
子系統01的method1()被呼叫！
子系統02的method2()被呼叫！
子系統03的method3()被呼叫！
每天下班時，關機前需要做三件事：
用程式模擬如下：
#include using namespace std;
// 子系統角色：瀏覽器類
class browser
static void close()
};// 子系統角色：ide類
class ide
static void close()
};// 子系統角色：wechat類
class wechat
static void close()
};int main()
上班:
開啟瀏覽器
開啟 ide
下班:關閉瀏覽器
關閉 ide
// 外觀角色
class facade
void close()
};
int main()
外觀模式就是這麼簡單，它使得兩種不同的類不用直接互動，而是通過乙個中介軟體——也就是外觀類——間接互動。外觀類中只需要暴露簡潔的介面，隱藏內部的細節，所以說白了就是封裝的思想。
外觀模式非常常用，（當然了！寫**哪有不封裝的！）尤其是在第三方庫的設計中，我們應該提供盡量簡潔的介面供別人呼叫。另外，在 mvc 架構中，c 層（controller）就可以看作是外觀類，model 和 view 層通過 controller 互動，減少了耦合。
參考：
知乎 - 如何學習設計模式？ 熱門回答
外觀模式（facade模式）詳解
菜鳥教程 - 設計模式篇
設計模式 結構型模式 外觀模式
粗淺地理解，外觀模式的核心思想就是把分散的方法集中到乙個方法a裡呼叫，外部只需要呼叫a方法就可以把所有的方法都跑一遍，簡單省事。例如上圖的病人看病流程。假設有guahao menzhen huajia quyao 4個方法，如果沒有外觀模式，100個地方用到這個流程，四個方法每個都要各寫100遍呼叫...
設計模式 結構型模式 外觀模式
組建乙個家庭影院 傳 統方式解決影院管理 clienttest 傳統方式解決影院管理問題分析 1 在clienttest 的main方法中，建立各個子系統的物件，並直接去呼叫子系統 物件 相關方法，會造成呼叫過程混亂，沒有清晰的過程 2 不利於在clienttest 中，去維護對子系統的操作 3 解...
結構型模式 外觀模式
外觀模式 facade 為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。外觀模式將客戶端與子系統的內部複雜性進行分隔開，使得客戶端只需要與外觀物件打交道，而不需要與子系統內部的很多物件打交道。外觀模式的目的在於減少系統的複雜程度。在物件導向軟體系...