门面模式（Facade Pattern）也叫做外观模式，是一种比较常用的封装模式，其定义如 下：Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.（要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）
简单的说，就是对外界提供一个接口来访问系统内部
- Facade门面角色
- subsystem子系统角色
门面角色：知晓子系统内部的所有功能和责任，一般情况下，该角色只是一个委托类，没有实际的执行权。
子系统角色：可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是由多个类组成的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。
就拿我们常说的日志门面slf4j(Simple Logging Facade for Java)来说，发现Logger类中都是抽象方法
再来看看logback，发现它实现了 slf4j 的全部方法，当我们项目中用的是slf4j + lockback时，我们通过门面slf4j就可以调用真正的执行者logback。当然，如果我想悄悄的换一个执行者，比如log4j，通过实现 slf4j 的全部方法也可以做到，而且，外界根本感知不到。
- 提高了灵活性
- 提高安全性
- 减少系统的相互依赖（避免外界访问直接深入到子系统内部）
- 不符合开闭原则
- 为一个复杂的模块或子系统提供一个供外界访问的接口
- 子系统相对独立——外界对子系统的访问只要黑箱操作即可
- 预防低水平人员带来的风险扩散
门面不参与子系统内的业务逻辑
下面这段代码，就使得门面也参与了业务的逻辑处理
public class Facade { //被委托的对象，也就是门面
private ClassA a = new ClassA();
private ClassB b = new ClassB();
private ClassC c = new ClassC();
//提供给外部访问的方法
public void methodA(){
this.a.doSomethingA();
}
public void methodB(){
this.b.doSomethingB();
}
//这个方法让门面进行了业务处理
public void methodC(){
this.a.doSomethingA();
this.c.doSomethingC();
}
}
门面对象只提供一个能访问子系统的路径，仅此而已，它不应该也不能参与具体的业务逻辑，否则就会产生一个倒依赖的问题：
子系统必须依赖门面才能被访问，这是设计上一个严重错误，不仅违反了单一职责原则，同时也破坏了系统的封装性。
