一、基本概念
門面模式（外觀模式）是物件的結構模式，外部與一個子系統的通信必須通過一個統一的門面物件進行，門面模式提供一個高層次的介面，使得子系統更易于使用，
二、通俗解釋
FACADE門面模式：我有一個專業的Nikon相機，我就喜歡自己手動調光圈、快門，這樣照出來的照片才專業，但MM可不懂這些，教了半天也不會，幸好相機有Facade設計模式，把相機調整到自動檔，只要對準目標按快門就行了，一切由相機自動調整，這樣MM也可以用這個相機給我拍張照片了， 門面模式：外部與一個子系統的通信必須通過一個統一的門面物件進行，門面模式提供一個高層次的介面，使得子系統更易于使用，每一個子系統只有一個門面類，而且此門面類只有一個實體，也就是說它是一個單例模式，但整個系統可以有多個門面類，
醫院的例子
現代的軟體系統都是比較復雜的，設計師處理復雜系統的一個常見方法便是將其“分而治之”，把一個系統劃分為幾個較小的子系統，如果把醫院作為一個子系統，按照部門職能，這個系統可以劃分為掛號、門診、劃價、化驗、收費、取藥等，看病的病人要與這些部門打交道，就如同一個子系統的客戶端與一個子系統的各個類打交道一樣，不是一件容易的事情，
首先病人必須先掛號，然后門診，如果醫生要求化驗，病人必須首先劃價，然后繳費，才可以到化驗部門做化驗，化驗后再回到門診室，
上圖描述的是病人在醫院里的體驗，圖中的方框代表醫院，
解決這種不便的方法便是引進門面模式，醫院可以設定一個接待員的位置，由接待員負責代為掛號、劃價、繳費、取藥等，這個接待員就是門面模式的體現，病人只接觸接待員，由接待員與各個部門打交道，
三、門面模式詳解
1.門面模式的結構
門面模式沒有一個一般化的類圖描述，最好的描述方法實際上就是以一個例子說明，
由于門面模式的結構圖過于抽象，因此把它稍稍具體點，假設子系統內有三個模塊，分別是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模塊的解耦，讓客戶端更容易地使用系統，
2.門面模式的實作
使用門面模式還有一個附帶的好處，就是能夠有選擇性地暴露方法，一個模塊中定義的方法可以分成兩部分，一部分是給子系統外部使用的，一部分是子系統內部模塊之間相互呼叫時使用的，有了Facade類，那么用于子系統內部模塊之間相互呼叫的方法就不用暴露給子系統外部了，
比如，定義如下A、B、C模塊，
public class ModuleA {
/**
* 提供給子系統外部使用的方法
*/
public void a1(){};
/**
* 子系統內部模塊之間相互呼叫時使用的方法
*/
public void a2(){};
public void a3(){};
}public class ModuleB {
/**
* 提供給子系統外部使用的方法
*/
public void b1(){};
/**
* 子系統內部模塊之間相互呼叫時使用的方法
*/
public void b2(){};
public void b3(){};
}public class ModuleC {
/**
* 提供給子系統外部使用的方法
*/
public void c1(){};
/**
* 子系統內部模塊之間相互呼叫時使用的方法
*/
public void c2(){};
public void c3(){};
}門面類：
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()方法是內部模塊之間互動的，原本就不是對子系統外部的，所以干脆就不要讓客戶端知道，
一個系統可以有幾個門面類
在門面模式中，通常只需要一個門面類，并且此門面類只有一個實體，換言之它是一個單例類，當然這并不意味著在整個系統里只有一個門面類，而僅僅是說對每一個子系統只有一個門面類，或者說，如果一個系統有好幾個子系統的話，每一個子系統都有一個門面類，整個系統可以有數個門面類，
為子系統增加新行為
初學者往往以為通過繼承一個門面類便可在子系統中加入新的行為，這是錯誤的，門面模式的用意是為子系統提供一個集中化和簡化的溝通管道，而不能向子系統加入新的行為，比如醫院中的接待員并不是醫護人員，接待員并不能為病人提供醫療服務，
3.門面模式的優點
門面模式的優點：
● 松散耦合
門面模式松散了客戶端與子系統的耦合關系，讓子系統內部的模塊能更容易擴展和維護，
● 簡單易用
門面模式讓子系統更加易用，客戶端不再需要了解子系統內部的實作，也不需要跟眾多子系統內部的模塊進行互動，只需要跟門面類互動就可以了，
● 更好的劃分訪問層次
通過合理使用Facade，可以幫助我們更好地劃分訪問的層次，有些方法是對系統外的，有些方法是系統內部使用的，把需要暴露給外部的功能集中到門面中，這樣既方便客戶端使用，也很好地隱藏了內部的細節，
四、門面模式在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等方法，這會危害安全性，
（參考：《JAVA與模式》之門面模式）
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/8576.html
標籤：設計模式