一.定义

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

二.类图

• Facade门面角色：客户端可以调用这个角色的方法，此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。
• SubSystem子系统角色：可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合，子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。

三.优点

• 减少系统间的相互依赖
• 提高了灵活性
• 提高安全性：想让你访问子系统的哪些业务就开通哪些逻辑，不在门面上开通的方法，无法访问到。

四.缺点

• 不符合开闭原则，对修改开放，对扩展关闭。系统投产后，维护只能修改门面角色代码，风险相当大。

五.使用场景

• 为一个复杂的模块或子系统提供一个供外界访问的接口
• 子系统相对独立——外界对子系统的访问只要黑箱操作即可。
• 预防低水平人员带来的风险扩散。比如一个低水平的技术人员参与项目开发，为降低个人代码质量对整体项目的影响风险，一般的做法是“画地为牢”，只能在指定的子系统中开发，然后再提供门面接口进行访问操作。

六.注意事项

• 一个子系统可以有多个门面。一个纯洁的门面对象已经超过200行代码，虽然都是非常简单的委托操作，建议按照功能拆分成多个门面，否则会给以后的维护和扩展带来不必要的麻烦。
• 门面不参与子系统的内部逻辑