門面（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 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()方法是內部模塊之間交互的，本來就不是對子系統外部的，因此乾脆就不要讓客戶端知道。

一個系統能夠有幾個門面類

　　在門面模式中，一般只須要一個門面類，而且此門面類只有一個實例，換言之它是一個單例類。固然這並不意味着在整個系統裏只有一個門面類，而僅僅 是說對每個子系統只有一個門面類。或者說，若是一個系統有好幾個子系統的話，每個子系統都有一個門面類，整個系統能夠有數個門面類。

爲子系統增長新行爲

　　初學者每每覺得經過繼承一個門面類即可在子系統中加入新的行爲，這是錯誤的。門面模式的用意是爲子系統提供一個集中化和簡化的溝通管道，而不能向子系統加入新的行爲。好比醫院中的接待員並非醫護人員，接待員並不能爲病人提供醫療服務。

門面模式的優勢

　　門面模式的優勢：

　　●　　鬆散耦合

　　門面模式鬆散了客戶端與子系統的耦合關係，讓子系統內部的模塊能更容易擴展和維護。

　　●　　簡單易用

　　門面模式讓子系統更加易用，客戶端再也不須要了解子系統內部的實現，也不須要跟衆多子系統內部的模塊進行交互，只須要跟門面類交互就能夠了。

　　●　　更好的劃分訪問層次

　　經過合理使用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等方法，這會危害安全性。