外觀模式說明
說明：外觀模式是用於由於子系統或程序組成較復雜而提供的一個高層界面接口，使用客戶端更容易訪問底層的程序或系統接口;
外觀模式是我們經常使用遇到的模式，我們經常涉及到的功能，可能需要涉及到幾個子接口或子系統，而我們的某個功能，可能只需要這向個多個子接口中的一個或幾個組成的順序封裝。如果是業務功能直接對應子接口或子系統的，可能要求開發人員對內部需要相當的了解；你可能需要去了解業務流程是怎麼走，他的順序是什麼，等等。這即需要開發員了解業務，也使得客戶端編程變得相當的復雜；
這裡如果有一層，或是一個類，專門提供好封裝好我們要使用的方法，客戶端功能只需要與這個中間層類交互，中間層類的相應方法有了解業務的相關開發人員組織封裝，那麼程序將變得非常的簡單，程序員只需要知道他這個功能所需要對應方法是哪個即可，也不用知道內部的邏輯。
這個中間層類就是我們說的外觀類，這就是外觀模式的思想。
場景實例:
1>. 比如總開關的例子，這個總開關，可以控制家裡的大門的一盞燈，大廳的幾盞燈，並控制著家電視機，電冰箱等的供電，你把哪個小按鈕按上“ON”，哪個就有了電，甚至直接發光輸熱，你不必知道，這總開關上的按鈕是怎麼出來電的，或是怎麼按制到相關電器的，反正直接壓上就來電了。
這些個電燈，電視機等就是我們要使用的接口，小系統；這個總開關就是我們的外觀類，我們直接面對它操作即可。
2>. 還好比一個公司，有好幾個職能部門，老板哪一天需要各方面工作的執行情況了，他就跑去一個個部門內部，問個員工說這個某某事情辦得怎麼樣了，如果問對人了能直接給老板答案，要是不是這個人負責的，他還會跟老板說，哦，這事是誰誰負責的，老板還得跑去問下那人，多麻煩。
如果每個職能部門設個主管負責人，老板直接去找它了解情況就可以了，老板也不用關心這個負責人是怎麼知道這些的，他只要想了解的這麼1,2,3件事情的情況跟進展即可。
實例源碼
現在按第二個實例場景實現源碼：
1. 幾個部門職能類:
部門1 (業務部門):
復制代碼 代碼如下:
function BusinessDept() {
this.manager = '陳經理'; //負責人
}
BusinessDept.prototype = {
MonthSales: function() {
console.log(this.manager + '說：這個月銷售額是xxx');
},
NextPlan: function() {
console.log(this.manager + '說：接下來的計劃是這樣的,xxxx');
}
}
部門2(研發部門):
復制代碼 代碼如下:
function RDdept() {
this.manager = '黃經理';
}
RDdept.prototype = {
progress: function() {
console.log(this.manager + '說：目前的項目情況跟進展是這樣的xxx');
},
deptPlan: function() {
console.log(this.manager + '說：接下來的部門規劃是這樣的xxx');
}
}
以上是各部門主管所要回答老板的問題;
接下來建立外觀類，用於組織老板想問的問題；
復制代碼 代碼如下:
function Facade() {
this.business = new BusinessDept() ;
this.rddept = new RDdept();
}
Facade.prototype = {
DeptSituation: function() {
this.business.MonthSales(); //銷售部經理先說;
this.rddept.progress();
},
deptPlan: function() {
this.business.NextPlan(); //報告接下來計劃;
this.rddept.deptPlan();
}
}
接下來老板把兩位經理叫到面前，開始問話了:
復制代碼 代碼如下:
var facade = new Facade();
console.log('老板問：現在介紹下自己部門的情況?');
facade.DeptSituation();
console.log('老板問：接下來有什麼規劃?');
facade.deptPlan();
其他說明
使用外觀模式，可以使得接口或類之間解耦，使得類之間不必產生依賴，不必要使用時得A包含B，或是B一定得包含A，這違反了關閉修改原則，使用中間層外觀類包裝，可以使得接口調用變得簡單，使用子接口或子系統對象調用變得更加自由可組織。
外觀模式經常出現我們的編程中，外觀模式經常使用在架構系統的模式定義中出現，我們的系統要使用第三方的接口服務，也經常再加層外觀層用於組織可用的業務接口;