定 义：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，门面模式提供一个高层次的接口，使得子系统更易于使用
优 点：
1、减少系统的相互依赖
2、提高了灵活性
3、提高了安全性
缺 点：最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放，
应用场景：
1、为一个复杂的模块或子系统提供一个供外界访问的接口
2、子系统相对独立--外界对子系统的访问只要黑箱操作即可
3、预防低水平人员带来的风险扩散
应用案例：
先来看看门面模式的类图：
Facade门面角色：客户端可以调用这个角色的方法，此角色知晓子系统的所有功能和责任，但是注意到此角色没有实际的业务逻辑，只是一个委托类。
Subsystem Classes：可以同时有一个或者多个子系统，每一个子系统都不是一个单独的类，而是一个类的集合，子系统并不知道门面的存在。
想一想现在邮寄一份邮件有多麻烦，首先我们得去购买信纸、信封，没笔还得准备好笔，然后就是写信，写好后封装好，然后再到邮寄去进行邮递，这个过程不允许出错，出错了就无法邮递出去了，对于个人来讲，这种邮递方式是在是太麻烦，我们想想门面模式，然后再想想发送邮件，是否可以利用该模式呢？如果我们将写信、装信、发信都交给邮局去做不是更加简单了吗？于是我们设计类图如下：
再看看上面的设计，对于用户来讲非常的方便，而且有利于扩充，如果某段时间警察要检查邮件内容才允许发布，那么在门面模块中增加一个检测方法就行，对用户来讲根本无从解释和说明。再来看一个令人非常头疼的东西，去医院，去医院后，我们要自己挂号，找门诊，看病，开单子，划价，化验，收费等，而这些都需要病人自己亲自去处理，这对病人来说是一个非常难以处理的问题，如果引入门面模式，由一个专门的接待部门来解决这些问题不是更好吗？等不急了，我先来看看这个UML图如何来实现：
