门面模式（Facade 外观模式，对象结构型模式）

意图

单一窗口
为了子系统中的一组接口提供一个一致的界面
定义了一个高层接口，这个接口使得对一个子系统更加容易使用，并且保证系统之间业务逻辑的正确使用

适用性

在遇到以下情况使用Facade 模式
1. 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来了一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
2. 客户程序与抽象类的实现部分之间存在很大的依赖性。引入facade将这个子类系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
3. 当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。如果子系统之间是相关依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们的依赖关系。
4. 为一个复杂子系统提供一个简单接口.
5. 提高子系统的独立性.
6. 在层次化结构中，可以使用Facade模式定义系统中每一层的入口。

结构

参与者

Facade

1. 知道哪些子系统负责处理请求
2. 将客户的请求代理给适当的子系统对象
3. 核心，被客户角色调用，完成对子系统的功能封装

Subsystem classes

1. 实现子系统的功能
2. 处理由Facade对象指派的任务
3. 没有Facade的任何相关的信息；即没有指向Facade的指针

Client

调用门面角色来完成业务逻辑功能

代码

public class SubsystemClass1 {    public void method1(){        System.out.println("=SubsystemClass1===method1====");    }}public class SubsystemClass2 {    public void method2(){        System.out.println("=SubsystemClass2===method2====");    }}public class Facade {    private SubsystemClass1 subsystemClass1;    private SubsystemClass2 subsystemClass2;    public Facade(SubsystemClass1 subsystemClass1,SubsystemClass2 subsystemClass2){        this.subsystemClass1 = subsystemClass1;        this.subsystemClass2 = subsystemClass2;    }    public void methodAll(){        subsystemClass1.method1();        subsystemClass2.method2();    }}public class Client {    public static void main(String[] args) {        Facade facade = new Facade(new SubsystemClass1(),new SubsystemClass2());        facade.methodAll();    }}

协作

1. 客户程序通过发送请求给Facade的方式与子系统通讯，Facade将这些消息转发给适当的子系统对象。尽管是子系统中的有关对象在做实际工作，但Facade模式本身也必须将它的接口转换成子系统的接口。
2. 使用Facade的客户程序不需要直接访问子系统对象。

效果

优点

1. 对客户屏蔽了其子系统组件，因而减少了客户处理对象的数目，并使得子系统实用起来更方便
2. 它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。 Facade模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。 Facade模式还可以消除复杂的循环依赖关系，这一点在客户程序与子系统是分别实现的时候尤为重要。
   在大兴软件系统中降低编译依赖至关重要。在子系统类改变时，希望尽量减少重编译工作已节省时间。用Facade可以降低编译依赖性，限制重要系统中较小的变化所需的重编译工作。Facade模式同样也有利于简化系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。
3. 如果应用需要，它并不限制它们实用子系统类。因此你可以在系统易用性和通用性之间进行选择。

缺点

限制了客户的自由，减少了可变性。

实现

降低客户-子系统之间的耦合度

用抽象类实现Facade而它的具体子类对应于不同的子系统实现，这可以进一步降低客户端与子系统的耦合度。这样，客户就可以通过抽象的Facade类接口与子系统通讯。这种抽象耦合关系使得客户不知道它使用的是子系统的哪一个实现。
除生成子类的方法以外，另一种方法是用不同的子系统对象配置Facade对象。为定制Facade，仅需对它的子系统对象（一个或者多个）进行替换即可。

公共子系统类与私有子系统类

一个子系统与一个类的相似之处是，它们都有接口并且都封装了一些东西，类封装了状态和操作，而子系统封装了一些类。考虑一个类的公有和私有接口是有益的，我们也可以考虑子系统的公有和私有接口。
子系统的公共接口包含所有的客户程序可以访问的类；私有接口仅用于对子系统进行扩充。当然，Facade类时公共接口的一部分，但它不是唯一的部分，子系统的其他部分通常也是公共的。
私有化子系统类确实有用，但是很少有面向对象的变成语言支持这一点。

经典例子

数据库处理的封装（JDBC）

相关模式

Abstract Factory Pattern

抽象工厂模式可以与Facade模式一起使用以提供一个接口，这一接口用来以一种子系统独立的方式创建子系统对象。Abstract Factory也可以替代Facade模式隐藏那些与平台相关的类。抽象工厂模式可以视为跟产生对象的复杂业务有关的门面模式，因为它提供了“只要调用即可产生对象的接口”。

Mediator Pattern

Mediator Pattern与Facade模式的相似之处是，它抽象了一些已有的类的功能。然而，Mediator 的目的是对同事之间的任意通信进行抽象，通常集中不属于任何单个对象的功能。Mediator的同事对象知道中介者并与它通信，而不是直接与其他同类对象通信。相对而言，Facade模式仅对子系统对象的接口进行抽象，从而使它们更容易使用；它并不定义新功能，子系统也不知道Facade的存在。
门面模式所产生的是让Facade参与者单方面利用其它参与者较高等级接口；而在Mediator Pattern中，Mediator参与者的处理行为比较类似Colleague参与者的中间人，可以说Facade Pattern是单行道的，而Mediator Pattern是双向通车。

Singleton Pattern

通常来讲只需要一个Facade对象，所以可以使用单利模式实现。
敬请期待“享元模式（羽量级模式、蝇量级模式Flyweight，对象结构型模式）”