对于开发人员来说，设计模式有时候就是一道坎，但是设计模式又非常有用，过了这道坎，它可以让你水平提高一个档次。而在android开发中，必要的了解一些设计模式又是必须的，因为设计模式在Android源码中，可以说是无处不在。对于想系统的学习设计模式的同学，这里推荐一本书，《大话设计模式》。

Android常用设计模式系列：

面向对象的基础特征
面向对象的设计原则
单例模式
模板模式
适配器模式
工厂模式
代理模式
原型模式
策略模式
Build模式
观察者模式
装饰者模式
中介模式
门面模式

一、门面模式

门面模式是对象的结构模式，外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

医院的例子

现代的软件系统都是比较复杂的，设计师处理复杂系统的一个常见方法便是将其“分而治之”，把一个系统划分为几个较小的子系统。如果把医院作为一个子系统，按照部门职能，这个系统可以划分为挂号、门诊、划价、化验、收费、取药等。看病的病人要与这些部门打交道，就如同一个子系统的客户端与一个子系统的各个类打交道一样，不是一件容易的事情。

首先病人必须先挂号，然后门诊。如果医生要求化验，病人必须首先划价，然后缴费，才可以到化验部门做化验。化验后再回到门诊室。

image.png

上图描述的是病人在医院里的体验，图中的方框代表医院。

解决这种不便的方法便是引进门面模式，医院可以设置一个接待员的位置，由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是门面模式的体现，病人只接触接待员，由接待员与各个部门打交道。

image.png

二、门面模式的结构

门面模式没有一个一般化的类图描述，最好的描述方法实际上就是以一个例子说明。

image.png

由于门面模式的结构图过于抽象，因此把它稍稍具体点。假设子系统内有三个模块，分别是ModuleA、ModuleB和ModuleC，它们分别有一个示例方法，那么此时示例的整体结构图如下：

image.png

在这个对象图中，出现了两个角色：

●　　门面(Facade)角色 ：客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。

●　　子系统(SubSystem)角色 ：可以同时有一个或者多个子系统。每个子系统都不是一个单独的类，而是一个类的集合（如上面的子系统就是由ModuleA、ModuleB、ModuleC三个类组合而成）。每个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。

也就是说，本来应该客户端来跟各个子系统来接触，但是有了门面模式之后，客户端有什么操作只需要跟门面来打交道，告诉门面类，下面的事情就交给门面来协调组织子系统来做。

使用门面模式：

不使用门面模式：

三、门面模式的实现

使用门面模式还有一个附带的好处，就是能够有选择性地暴露方法。一个模块中定义的方法可以分成两部分，一部分是给子系统外部使用的，一部分是子系统内部模块之间相互调用时使用的。有了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()方法是内部模块之间交互的，原本就不是对子系统外部的，所以干脆就不要让客户端知道。

初学者往往以为通过继承一个门面类便可在子系统中加入新的行为，这是错误的。门面模式的用意是为子系统提供一个集中化和简化的沟通管道，而不能向子系统加入新的行为。比如医院中的接待员并不是医护人员，接待员并不能为病人提供医疗服务。

四、模式应用讲解

1、门面模式在Tomcat中的使用

Tomcat中门面模式使用的很多，因为Tomcat中有很多不同组件，每个组件要相互通信，但是又不能将自己内部数据过多的暴露给其他组件。用门面模式隔离数据是个很好的方法。

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

image.png

使用过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中的方法。如下图所示

image.png

注意红色方框圈中的类，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等方法，这会危害安全性。

2、Android中的门面模式

Context是最重要的一个类型。它封装了很多重要的操作，比如startActivity()、sendBroadcast()等，几乎是开发者对应用操作的统一入口。Context是一个抽象类，它只是定义了抽象接口，真正的实现在ContextImpl类中。它就类似于门面类。

另外在Android里面我们往往会写各种各样的工具来，这些工具类可以帮我们完成各种各样的操作或者帮我们获取到各种各样的信息，它也相当于一个门面类，使用了门面模式，我们需要什么操作直接调用就可以，它屏蔽了底层的实现。

五、门面模式的优缺点

优点：

• 松散耦合
  减少系统的相互依赖，上面也提到不使用门面模式，外界访问直接深入到子系统内部，相互之间是一种强耦合关系这样的强依赖是系统设计所不能接受的，门面模式的出现就很好地解决了该问题，所有的依赖都是对门面对象的依赖，与子系统无关。

• 简单易用
  门面模式让子系统更加易用，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟门面类交互就可以了。

• 更好的划分访问层次
  通过合理使用Facade，可以帮助我们更好地划分访问的层次。有些方法是对系统外的，有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中，这样既方便客户端使用，也很好地隐藏了内部的细节。

• 提高安全性
  访问子系统的哪些业务就开通哪些逻辑，不需要把子系统的内部方法直接暴露给外部调用。

缺点

• 门面模式最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放。

• 系统投产后发现问题唯一能做的一件事就是修改门面角色的代码，这个风险相当大。

六 结语

门面模式是一个很好的封装方法，一个子系统比较复杂时，比如算法或者业务比较复杂，就可以封装出一个或多个门面出来，项目的结构简单，而且扩展性非常好。还有，对于一个较大项目，为了避免人员带来的风险，也可以使用门面模式。

门面模式和 中介模式

• 1、从定义上，门面模式为复杂的子系统提供一个统一的访问界面，它定义的是一个高层接口，该接口使得子系统更加容易使用，避免外部模块深入到子系统内部而产生与子系统内部细节耦合的问题。中介者模式使用一个中介对象来封装一系列同事对象的交互行为，它使各对象之间不再显式地引用，从而使其耦合松散，建立一个可扩展的应用架构。

• 2、从功能上，门面模式只是增加了一个门面，它对子系统来说没有增加任何的功能，子系统若脱离门面模式是完全可以独立运行的。而中介者模式则增加了业务功能，它把各个同事类中的原有耦合关系移植到了中介者，同事类不可能脱离中介者而独立存在。

• 3、从关系上，对门面模式来说，子系统不知道有门面存在，而对中介者来说，每个同事类都知道中介者存在，因为要依靠中介者调和同事之间的关系，它们对中介者非常了解。

• 4、从封装程度上，门面模式是一种简单的封装，所有的请求处理都委托给子系统完成，而中介者模式则需要有一个中心，由中心协调同事类完成，并且中心本身也完成部分业务，它属于更进一步的业务功能封装。