门面（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等方法，这会危害安全性。