概述
外观模式Facade是一种结构型设计模式， 能为程序库、 框架或其他复杂类提供一个简单的接口。
外观模式的核心思想是通过创建一个外观类（Facade Class），将客户端与子系统之间的复杂交互过程封装起来。客户端只需要与外观类进行交互，而不需要直接与子系统的组件进行交互。这样可以降低客户端与子系统之间的耦合度，提供了一种简化接口的方式，使得客户端代码更加清晰和易于维护。
- 客户端 （Client） 使用外观代替对子系统对象的直接调用。
- 外观 （Facade） 提供了一种访问特定子系统功能的便捷方式， 其了解如何重定向客户端请求， 知晓如何操作一切活动部件。
- 还可创建附加外观 （Additional Facade） 类可以避免多种不相关的功能污染单一外观， 使其变成又一个复杂结构。 客户端和其他外观都可使用附加外观。
- 子系统（Subsystem）：由多个相互关联的类组成，实现了复杂的功能。外观类将客户端的请求转发给子系统进行处理。如类图中的多个class
适用场景
-
简化复杂子系统：当系统中存在多个复杂的子系统，且它们之间有复杂的交互关系时，可以使用外观模式来为客户端提供一个简化的接口，隐藏子系统的复杂性，使得客户端更易于使用子系统的功能。
-
客户端与子系统解耦：当客户端需要与多个子系统组件进行交互，且这些交互关系频繁变化时，可以使用外观模式来将客户端与子系统解耦。客户端只需要与外观类进行交互，不需要关心子系统的内部结构和组件之间的具体交互方式。
-
提供统一接口：当系统中的一组接口或类存在一定的依赖关系或调用顺序时，可以使用外观模式将它们封装成一个统一的接口，简化客户端的调用流程。
-
限制客户端访问权限：当系统中的某些功能对客户端是敏感或不希望被直接访问时，可以使用外观模式来隐藏这些功能，只提供有限的接口供客户端使用。
-
系统升级和重构：当系统的内部结构发生变化时，使用外观模式可以降低对客户端的影响。客户端只需要调用外观类的接口，而不需要关心内部结构的改变。 需要注意的是，外观模式并不是为了解决系统本身的复杂性，而是为了简化客户端对系统的使用。在使用外观模式时，需要权衡好系统的设计和模块的划分，确保封装后的外观类不会变得过于臃肿和复杂。
对比
- 适配器模式（Adapter Pattern）：
- 相似性：外观模式和适配器模式都是结构型设计模式，都是用于简化客户端与其他组件的交互。
- 区别：适配器模式是用于将一个接口转换为另一个接口，使得原本不兼容的接口可以一起工作；而外观模式是用于封装一组接口或类，提供一个更简化的接口供客户端使用。
- 当只需对客户端代码隐藏子系统创建对象的方式时， 你可以使用抽象工厂模式来代替外观
- 外观类通常可以转换为单例模式类， 因为在大部分情况下一个外观对象就足够了。
- 外观与代理模式的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。代理与其服务对象遵循同一接口， 使得自己和服务对象可以互换， 在这一点上它与外观不同