定義

門面模式是對象的結構模式，外部與一個子系統的通信必須通過一個統一的門面對象進行。門面模式提供一個高層次的接口，使得子系統更易于使用。

醫(yī)院的例子

現在的軟件系統都是比較復雜的，設計師處理復雜問題的一個常見方法就是將其“分而治之”，把一個系統拆分成幾個較小的子系統。如果把一個醫(yī)院作為一個軟件系統，按照部門職能，這個系統可以劃分為掛號、門診、劃價、化驗、收費、取藥等多個子系統。看病的病人需要同這些部門打交道，就如同一個系統的客戶端與系統的各個類打交道一樣，不是一件容易的事情。

首先病人必須先掛號，然后門診。如果醫(yī)生要求化驗，則病人需要先劃價，然后繳費，才能到化驗部門進行化驗檢查。拿到化驗結果后，再回到門診室。

醫(yī)院就診流程

上圖描述的是病人在醫(yī)院里的體驗，圖中的方框代表醫(yī)院。

解決這種不變的方法就是引進門面模式，醫(yī)院可以設置一個接待員的位置，由接待員負責代為掛號、劃價、繳費、取藥等過程。這個接待員就是門面模式的體現，病人只需要接觸接待員，由接待員與各個部門打交道。

醫(yī)院門面模式體現

門面模式的結構

門面模式沒有一個一般化的類圖描述，最好的描述方法實際上就是以一個例子說明。

門面模式結構圖

由于門面模式的結構圖過于抽象，因此把它稍微具體一點。假設系統有三個模塊，分別是ModuleA、ModuleB和ModuleC，他們分別有一個示例方法，那么此時示例的整體結構圖如下：

門面模式具體設計圖示例

在這個對象圖中，出現了兩個角色：

• 門面角色(Facade)：客戶端可以調用這個角色的方法。此角色知曉相關的(一個或多個)子系統的功能和責任。在正常情況下，本角色會將所有從客戶端發(fā)來的請求委派到相應的子系統去。
• 子系統角色(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 moduleA = new ModuleA();
        moduleA.testA();
        ModuleB moduleB = new ModuleB();
        moduleB.testB();
        ModuleC moduleC = new ModuleC();
        moduleC.testC();
    }
}

客戶端角色類

public class Client {
    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.test();
    }
}

Facade類其實相當于A、B、C模塊的外觀界面，有了這個Facade類，那么客戶端就不需要親自調用子系統中的A、B、C模塊了，也不需要知道系統內部的實現細節(jié)，甚至都不需要知道A、B、C模塊的存在，客戶端只需要跟Facade類交互就好了，從而更好的實現了客戶端和子系統中A、B、C模塊的解耦，讓客戶端更容易的使用系統。

門面模式的實現

使用門面模式還有一個附帶的好處，就是能夠有選擇性的暴露方法。一個模塊中定義的方法可以分成兩部分：一部分是給子系統外部使用的；一部分是子系統內部模塊之間相互調用時使用的。有了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類可以有效的屏蔽內部的細節(jié)，免得客戶端去調用Module的相關類時，發(fā)現一些不需要它知道的方法，比如a2()和a3()方法就不需要讓客戶端知道，否則既暴露了內部的細節(jié)，又讓客戶端迷惑。對客戶端來說，他可能還需要去考慮a2()和a3()方法的作用。其實a2()和a3()方法是內部模塊之間交互的，原本就不是對子系統外部的，所以干脆就不要讓客戶端知道。

一個系統可以有幾個門面類

在門面模式中，通常只需要一個門面類，并且此門面類只有一個實例，換句話說，它是一個單例類。當然這并不意味著在整個系統中只能有一個門面類，而僅僅是說對于一個子系統只有一個門面類?；蛘哒f，如果一個系統有好幾個子系統的話，每個子系統都有一個門面類，整個系統可以有數個門面類。

為子系統增加新行為

初學者往往認為通過繼承一個門面類便可以在子系統中加入新的行為，這是錯誤的。門面模式的用意是為子系統提供一個集中化和簡化的溝通管道，而不能向子系統中增加新的行為。比如醫(yī)院中的接待人員不是醫(yī)護人員，接待員并不能為病人提供醫(yī)療服務。

門面模式的優(yōu)點

• 松散耦合
  門面模式松散了客戶端與子系統的耦合關系，讓子系統內部的模塊能更容易拓展和維護。
• 簡單易用
  門面模式讓子系統更加易用，客戶端不再需要了解子系統內部的實現，也不需要跟眾多子系統內部的模塊進行交互，只需要跟門面類交互即可。
• 更好的劃分訪問層次
  通過合理的使用門面模式Facade，可以幫助我們更好的劃分訪問的層次。有些方法是對系統外部的，有些方法是對系統內部使用的。把需要暴露給外部的功能集中到門面類中，這樣既方便客戶端使用，也很好的隱藏了內部的細節(jié)。

門面模式在Tomcat中的使用

Tomcat中門面模式使用的很多，因為Tomcat中有很多不同組件，每個組件要相互通信，但是又不能將自己的內部數據過多的暴露給其他組件。用門面模式隔離數據是很好的方法。

下面是Request上使用的門面模式：

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會發(fā)現，在真正調用TestServlet之前，會經歷很多Tomcat中的方法。如下圖所示：

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與模式》之門面模式