版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u011815404/article/details/89678020
【概述】
外观模式为子系统中的外部与其内部的通信提供了一个统一的外观对象，即定义了一个高层接口，使得子系统更容易使用。
外观模式的外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的诸多对象打交道。
本质：封装交互、简化调用
【UML】
外观模式涉及到了两个角色：
- 外观角色：Facade，客户端可以调用这个角色的方法，此角色知晓相关的子系统的功能和责任，在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统。
- 子系统角色： 可以同时有一个或多个子系统，每一个子系统都不是一个单独的类，而是一个类的集合，每一个子系统都可以被客户端直接调用，或被门面角色调用，但子系统并不知道外观角色的存在，对其而言外观角色仅是另外一个客户端。
【优缺点】
优点：
- 屏蔽了外部客户端和系统内部模块的交互
- Facade 的功能可以被多个客户端调用，可以实现复用（功能的共享）
- 对使用 Facade 的人员来说，Facade 大大的节省了的学习成本
缺点：不符合开闭原则
【应用】
1.为一个复杂子系统提供一个简单接口
子系统往往因为不断演化而变得越来越复杂，大多数模式使用时都会产生更多更小的类，这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。
Facade 可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而需要可定制性的用户可以越过 Facade 层。
2.当客户程序与抽象类的实现部分之间存在着很大的依赖性时
引入 Facade 将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
3.使用层次化结构时
在层次化结构中，可以使用外观模式定义系统中每一层的入口点，如果子系统之间是相互依赖的，则可以让他们仅通过 Facade 进行通信，从而简化他们之间的依赖关系。
4.希望包装或隐藏原有系统时
Facade 可以把原有系统作为自己的私有成员，原有系统与 Facade 类联系在一起，但使用 Facade 类的客户无法看到原有的系统。
因此，其可维护一个遗留的大型系统，也可跟踪对系统的使用，从而强迫所有客户通过 Facade 使用原有系统。