外觀模式又稱為門面模式Facade是一種簡單的設計模式，但是他背後的思想為迪米特原則，理解門面模式更有助於理解迪米特原則--不要和陌生人說話的原則，可以降低系統的耦合程度，本文介紹了外觀模式的意圖，結構，並且給出了java代碼示例。 ...
外觀模式（FACADE） 又稱為門面模式
意圖
為子系統中的一組介面提供一個一致的界面 Facade模式定義了一個高層介面，這一介面使得這一子系統更加易於使用。意圖解析
隨著項目的持續發展，系統基本上都是會往功能更全面的方向發展，那麼也就意味著我們的系統將會變得更加複雜。 系統會被劃分為多個單獨的子系統，每個子系統完成一部分功能，通過分工協作完成全部功能。 一個子系統也可能進一步拆分為更小的幾個子系統。 程式中的文件將會越來越多，相互關聯也會變得更加複雜 當使用一個功能的時候，作為客戶端 你需要弄清楚相關類之間的關係，以及正確的調用順序。 比如下圖中 你需要自己識別有哪些子系統，涉及哪些相關的類和方法，你需要自己保證順序（如果功能調用依賴順序的話）
如同在醫院裡面，病人需要自己去排隊掛號化驗，跟每個流程的工作人員進行協作
如同在工廠裡面，需要生產一個桌子，你親自用機器生產桌子腿，自己使用機器生產桌面...
如同你去其他公司洽談業務，你單獨跟每個相關業務的人員進行聯繫溝通
你肯定想得到，如果有一個中間人為你代勞
不需要面對林林總總的子系統、部門、人員...
當你需要某種服務時，只需要告訴這個中間人就好了
這個想法就是外觀模式
有了facade，你就不需要跟每個子系統進行單獨的交流了
如同在醫院裡面，對於VIP，有專人代替你掛號.....
如同在工廠裡面，有一個控制台機器，你選擇產品，控制臺下發命令安排其他的機器生產具體產品
如同你去其他公司洽談業務，有一個介面人負責與你對接，他們那邊的事情都通過這個人進行安排
外觀模式的意圖含義，如同他的名字一樣，“建築物的正面”
面對一個複雜的大樓，當你在正面遠遠望去，也就只能看到正面
在外觀模式中，形容一個龐大的複雜的系統的一個直觀的界面
藉助於Facade模式
從原來的“客戶端需要跟多個子系統進行交互”，轉變為“只與Facade進行交互”
將客戶端與子系統進行解耦，降低了耦合性，也降低了使用的複雜度
代碼示例
“關好門窗，防火防盜”這句話有沒有聽過？ 回想一下，當你早上準備出門離開家時，你會做什麼？ 假設你會關水、關燈、關門窗。 我們創建三個類，水 燈 窗，模擬離開家的場景package facade; public class Water { public void turnOn() { System.out.println("打開水龍頭..."); } public void turnOff() { System.out.println("關閉水龍頭..."); } }
package facade; public class Light { public void turnOn() { System.out.println("開燈..."); } public void turnOff() { System.out.println("關燈..."); } }
package facade; public class Window { public void open() { System.out.println("開窗..."); } public void close() { System.out.println("關窗..."); } }測試代碼
上面的測試代碼Test作為客戶端程式，可以看得出來，他直接跟Water Light Window三個類的對象進行交互
他需要調用相關的方法
也就是說Test 作為客戶端對於“離家”這一系統的內部邏輯是瞭如指掌的--->需要斷水、關燈、關窗
他也清楚每個類的方法
一方面增加了耦合性，另一方面將子系統的內部細節暴露出來
優化重構
試想下，如果你家是智能家居，有一個控制台Facade，或者說有一個手機App 他可以控制整個家庭的設備package facade; public class Facade { private Water water = new Water(); private Light light = new Light(); private Window window = new Window(); public void leaveHome(){ water.turnOff(); light.turnOff(); window.close(); } public void backHome(){ light.turnOn(); window.open(); } }
通過這個控制台，客戶端程式不再需要瞭解子系統的內部細節，他也不清楚每個類到底有哪些方法
所有的交互都是通過Facade來完成的
結構
Facade 外觀角色
客戶端調用角色，知曉子系統的所有功能與職責
通常，Facade會將所有的請求轉發委派到子系統中去，也就是說該角色沒有實際的業務、
SubSystem子系統角色
可以同時有一個或者多個子系統
註意 :子系統並不是說一個單獨的類，而是一個類的集合，這些類根據邏輯功能點被組織在一起
子系統並不知道Facade的存在，對於子系統來說，Facade也就只是一個客戶端程式
外觀模式的結構比較簡單，類似一個“封裝”提取的過程
他的根本原則為迪米特法則，也就是“不要和陌生人說話”，儘可能少的與其他的對象進行交互
通過外觀模式，做到了子系統只與外觀對象交互
門面類個數
在門面模式中，通常只需要一個門面類，並且這個門面類只有一個實例
換句話說他很可能是一個單例
但是並不是說整個系統中只能有一個門面類
門面類的個數要根據系統中子系統的個數以及業務邏輯的情況
