## 引入 外觀模式又稱為門面模式。 在閻宏博士的《JAVA與模式》一書中開頭是這樣描述門面（Facade）模式的： > 門面模式是對象的結構模式，外部與一個子系統的通信必須通過一個統一的門面對象進行。門面模式提供一個高層次的接口，使得子系統更易于使用。 **醫院的例子** 現代的軟件系統都是比較復雜的，設計師處理復雜系統的一個常見方法便是將其“分而治之”，把一個系統劃分為幾個較小的子系統。如果把醫院作為一個子系統，按照部門職能，這個系統可以劃分為掛號、門診、劃價、化驗、收費、取藥等。看病的病人要與這些部門打交道，就如同一個子系統的客戶端與一個子系統的各個類打交道一樣，不是一件容易的事情。 　　首先病人必須先掛號，然后門診。如果醫生要求化驗，病人必須首先劃價，然后繳費，才可以到化驗部門做化驗。化驗后再回到門診室。  上圖描述的是病人在醫院里的體驗，圖中的方框代表醫院。 　　解決這種不便的方法便是引進門面模式，醫院可以設置一個接待員的位置，由接待員負責代為掛號、劃價、繳費、取藥等。這個接待員就是門面模式的體現，病人只接觸接待員，由接待員與各個部門打交道。  ## 定義 所謂外觀模式就是提供一個統一的接口，用來訪問子系統中的一群接口。 外觀模式定義了一個高層接口，讓子系統更容易使用。引入外觀模式后，客戶只需要與外觀角色打交道，客戶與子系統的復雜關系有外觀角色來實現，從而降低了系統的耦合度。 ## 結構 門面模式沒有一個一般化的類圖描述，最好的描述方法實際上就是以一個例子說明。  由于門面模式的結構圖過于抽象，因此把它稍稍具體點。假設子系統內有三個模塊，分別是ModuleA、ModuleB和ModuleC，它們分別有一個示例方法，那么此時示例的整體結構圖如下：  在這個對象圖中，出現了兩個角色： 　　●　　門面(Facade)角色 ：客戶端可以調用這個角色的方法。此角色知曉相關的（一個或者多個）子系統的功能和責任。在正常情況下，本角色會將所有從客戶端發來的請求委派到相應的子系統去。 　　●　　子系統(SubSystem)角色 ：可以同時有一個或者多個子系統。每個子系統都不是一個單獨的類，而是一個類的集合（如上面的子系統就是由ModuleA、ModuleB、ModuleC三個類組合而成）。每個子系統都可以被客戶端直接調用，或者被門面角色調用。子系統并不知道門面的存在，對于子系統而言，門面僅僅是另外一個客戶端而已。 ## 代碼實現 子系統角色中的類： ~~~ public class ModuleA { //示意方法 public void testA(){ System.out.println("調用ModuleA中的testA方法"); } } ~~~ ~~~ public class ModuleB { //示意方法 public void testB(){ System.out.println("調用ModuleB中的testB方法"); } } ~~~ ~~~ public class ModuleC { //示意方法 public void testC(){ System.out.println("調用ModuleC中的testC方法"); } } ~~~ 　門面角色類： ~~~ public class Facade { //示意方法，滿足客戶端需要的功能 public void test(){ ModuleA a = new ModuleA(); a.testA(); ModuleB b = new ModuleB(); b.testB(); ModuleC c = new ModuleC(); c.testC(); } } ~~~ 客戶端角色類： ~~~ public class Client { public static void main(String[] args) { Facade facade = new Facade(); facade.test(); } } ~~~ 　Facade類其實相當于A、B、C模塊的外觀界面，有了這個Facade類，那么客戶端就不需要親自調用子系統中的A、B、C模塊了，也不需要知道系統內部的實現細節，甚至都不需要知道A、B、C模塊的存在，客戶端只需要跟Facade類交互就好了，從而更好地實現了客戶端和子系統中A、B、C模塊的解耦，讓客戶端更容易地使用系統。 **門面模式的實現** 使用門面模式還有一個附帶的好處，就是能夠有選擇性地暴露方法。一個模塊中定義的方法可以分成兩部分，一部分是給子系統外部使用的，一部分是子系統內部模塊之間相互調用時使用的。有了Facade類，那么用于子系統內部模塊之間相互調用的方法就不用暴露給子系統外部了。 比如，定義如下A、B、C模塊。 ~~~ public class Module { /** * 提供給子系統外部使用的方法 */ public void a1(){}; /** * 子系統內部模塊之間相互調用時使用的方法 */ public void a2(){}; public void a3(){}; } ~~~ ~~~ public class ModuleFacade { ModuleA a = new ModuleA(); ModuleB b = new ModuleB(); ModuleC c = new ModuleC(); /** * 下面這些是A、B、C模塊對子系統外部提供的方法 */ public void a1(){ a.a1(); } public void b1(){ b.b1(); } public void c1(){ c.c1(); } } ~~~ 這樣定義一個ModuleFacade類可以有效地屏蔽內部的細節，免得客戶端去調用Module類時，發現一些不需要它知道的方法。比如a2()和a3()方法就不需要讓客戶端知道，否則既暴露了內部的細節，又讓客戶端迷惑。對客戶端來說，他可能還要去思考a2()、a3()方法用來干什么呢？其實a2()和a3()方法是內部模塊之間交互的，原本就不是對子系統外部的，所以干脆就不要讓客戶端知道。 **一個系統可以有幾個門面類** 　　在門面模式中，通常只需要一個門面類，并且此門面類只有一個實例，換言之它是一個單例類。當然這并不意味著在整個系統里只有一個門面類，而僅僅是說對每一個子系統只有一個門面類。或者說，如果一個系統有好幾個子系統的話，每一個子系統都有一個門面類，整個系統可以有數個門面類。 **為子系統增加新行為** 　　初學者往往以為通過繼承一個門面類便可在子系統中加入新的行為，這是錯誤的。門面模式的用意是為子系統提供一個集中化和簡化的溝通管道，而不能向子系統加入新的行為。比如醫院中的接待員并不是醫護人員，接待員并不能為病人提供醫療服務。 ## 門面模式在Tomcat中的使用 Tomcat中門面模式使用的很多，因為Tomcat中有很多不同組件，每個組件要相互通信，但是又不能將自己內部數據過多的暴露給其他組件。用門面模式隔離數據是個很好的方法。 　　下面是Request上使用的門面模式：  使用過Servlet的人都清楚，除了要在web.xml做相應的配置外，還需繼承一個叫HttpServlet的抽象類，并且重寫doGet與doPost方法（當然只重寫service方法也是可以的）。 ~~~ public class TestServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { this.doPost(request, response); } public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { } } ~~~ 可以看出doGet與doPost方法有兩個參數，參數類型是接口HttpServletRequest與接口HttpServletResponse，那么從Tomcat中傳遞過來的真實類型到底是什么呢？通過debug會發現，在真正調用TestServlet類之前，會經過很多Tomcat中的方法。如下圖所示  注意紅色方框圈中的類，StandardWrapperValue類中的invoke方法225行代碼如下： ~~~ filterChain.doFilter (request.getRequest(), response.getResponse()); ~~~ 在StandardWrapperValue類中并沒有直接將Request對象與Response對象傳遞給ApplicationFilterChain類的doFilter方法，傳遞的是RequestFacade與ResponseFacade對象，為什么這么說呢，看一下request.getRequest()與response.getResponse()方法就真相大白了。 Request類 ~~~ public HttpServletRequest getRequest() { if (facade == null) { facade = new RequestFacade(this); } return facade; } ~~~ Response類 ~~~ public HttpServletResponse getResponse() { if (facade == null) { facade = new ResponseFacade(this); } return (facade); } ~~~ 可以看到它們返回都是各自的一個門面類，那么這樣做有什么好處呢？ 　　Request對象中的很多方法都是內部組件之間相互交互時使用的，比如setComet、setRequestedSessionId等方法（這里就不一一列舉了）。這些方法并不對外部公開，但是又必須設置為public，因為還需要跟內部組件之間交互使用。最好的解決方法就是通過使用一個Facade類，將與內部組件之間交互使用的方法屏蔽掉，只提供給外部程序感興趣的方法。 　　如果不使用Facade類，直接傳遞的是Request對象和Response對象，那么熟悉容器內部運作的程序員可以分別把ServletRequest和ServletResponse對象向下轉換為Request和Response，并調用它們的公共方法。比如擁有Request對象，就可以調用setComet、setRequestedSessionId等方法，這會危害安全性。 ## 優點 * 松散耦合 門面模式松散了客戶端與子系統的耦合關系，讓子系統內部的模塊能更容易擴展和維護。 * 簡單易用 門面模式讓子系統更加易用，客戶端不再需要了解子系統內部的實現，也不需要跟眾多子系統內部的模塊進行交互，只需要跟門面類交互就可以了。 * 更好的劃分訪問層次 通過合理使用Facade，可以幫助我們更好地劃分訪問的層次。有些方法是對系統外的，有些方法是系統內部使用的。把需要暴露給外部的功能集中到門面中，這樣既方便客戶端使用，也很好地隱藏了內部的細節。 ## 缺點 * 不能很好地限制客戶使用子系統類，如果對客戶訪問子系統類做太多的限制則減少了可變性和靈活性 * 在不引入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則” ## 使用場景 * 當你要為一個復雜子系統提供一個簡單接口時。子系統往往因為不斷演化而變得越來越復雜。大多數模式使用時都會產生更多更小的類。這使得子系統更具可重用性，也更容易對子系統進行定制，但這也給那些不需要定制子系統的用戶帶來一些使用上的困難。Facade可以提供一個簡單的缺省視圖，這一視圖對大多數用戶來說已經足夠，而那些需要更多的可定制性的用戶可以越過Facade層。 * 客戶程序與抽象類的實現部分之間存在著很大的依賴性。引入Facade將這個子系統與客戶以及其他的子系統分離，可以提高子系統的獨立性和可移植性。 * 當你需要構建一個層次結構的子系統時，使用門面模式定義子系統中每層的入口點。如果子系統之間是相互依賴的，你可以讓它們僅通過Facade進行通訊，從而簡化了它們之間的依賴關系。 ## 總結 * 1、 外觀模式的主要優點就在于減少了客戶與子系統之間的關聯對象，使用客戶對子系統的使用變得簡單了，也實現了客戶與子系統之間的松耦合關系。它的缺點就在于違背了“開閉原則”。 * 2、 如果需要實現一個外觀模式，需要將子系統組合進外觀中，然后將工作委托給子系統執行。