JAVA設計模式之門面模式

標籤：

在閻宏博士的《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 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等方法，這會危害安全性。

　　

　　

　　

　　

　　

JAVA設計模式之門面模式