外观（Facade）模式又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。
在日常编码工作中，我们都在有意无意的大量使用外观模式。只要是高层模块需要调度多个子系统（2个以上的类对象），我们都会自觉地创建一个新的类封装这些子系统，提供精简的接口，让高层模块可以更加容易地间接调用这些子系统的功能。尤其是现阶段各种第三方SDK、开源类库，很大概率都会使用外观模式。
外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点:
- 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
- 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
- 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。
外观（Facade）模式的主要缺点如下:
- 不能很好地限制客户使用子系统类，很容易带来未知风险。
- 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
外观模式的结构与实现
外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。
1. 模式的结构
外观（Facade）模式包含以下主要角色。
- 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
- 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
- 客户（Client）角色：通过一个外观角色访问各个子系统的功能。
用例分析:
分析
门面模式思想比较简单。实际系统中包含多个子系统，完成一项任务需要多个子系统通力合作。我们可以选择将子系统所有接口暴露给Client，让Client自行调用。但这会导致一些问题，一是后期沟通成本会很高，加入完成一个功能需要调用多个接口，Client联调时出问题率会飙升，系统提供者需要不断答疑。二是如果有多个Client，相同代码Client需要重复开发，而且后期代码有变更，各方都会很烦费力。三是影响响应时间和性能，多个接口往返，白白增加了很多通信时间和请求量。
另一种方式是，对于指定功能，系统端做好封装，只提供一个接口。好处有很多，沟通成本低、Client不需要重复开发、功能更改影响范围小、提高响应时间和性能。一般这些接口会有对应的OpenAPI，实现了功能对外开放的效果。
使用场景
对于使用场景，简单的举一个例子。
电商系统一般包含商品、库存、营销、商家、交易、支付、售后、履约、物流、仓储等子系统。拿商品详情页来说，商详页接口一般会涉及商品、库存、营销、商家等系统。电商系统的客户端有PC、Mobile、Android、IOS等，为了避免让这些客户端调用接口拼凑出商详页的数据，一般商品组同学会提供商详页接口，通过该接口获取商详页的所有信息，返回给客户端。
当然，如果流量特别大，需要优化接口性能，可以根据具体情况将接口做拆分，客户端需要请求多个接口，但即使这样，相关的接口也是封装好的。
代码实现
外观模式的应用场景
通常在以下情况下可以考虑使用外观模式。
- 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
- 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
- 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。
外观模式的扩展
在外观模式中，当增加或移除子系统时需要修改外观类，这违背了“开闭原则”。如果引入抽象外观类，则在一定程度上解决了该问题，如下图所示。
