外观模式能为程序库、框架或其他复杂类提供一个简单的接口，亦称为门面模式，英文全称是 Facade Design Pattern.

为了保证接口的可复用性（或者叫通用性），我们需要将接口尽量设计得细粒度一点，职责单一一点。但是，如果接口的粒度过小，在接口的使用者开发一个业务功能时，就会导致需要调用 n 多细粒度的接口才能完成。调用者肯定会抱怨接口不好用。

如果接口粒度设计得太大，一个接口返回 n 多数据，要做 n 多事情，就会导致接口不够通用、可复用性不好。接口不可复用，那针对不同的调用者的业务需求，我们就需要开发不同的接口来满足，这就会导致系统的接口无限膨胀。

外观模式可解决接口的可复用性（通用性）和易用性之间的矛盾。尽量保持接口的可复用性，但针对特殊情况，允许提供冗余的外观接口，来提供更易用的接口。

1. 外观模式的实现原理

Provide a unified interface to a set of interfaces in a subsystem. Facade Pattern defines a higher-level interface that makes the subsystem easier to use.

外观模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用。“子系统（subsystem）”也可以有多种理解方式。它既可以是一个完整的系统，也可以是更细粒度的类或者模块

假设有一个系统 A，提供了 a、b、c、d 四个接口。系统 B 完成某个业务功能，需要调用 A 系统的 a、b、d 接口。利用外观模式，我们提供一个包裹 a、b、d 接口调用的外观接口 x，给系统 B 直接使用。系统 A 是一个后端服务器，系统 B 是 App 客户端。App 客户端通过后端服务器提供的接口来获取数据。App 和服务器之间是通过移动网络通信的，网络通信耗时比较多，为了提高 App 的响应速度，要尽量减少 App 与服务器之间的网络通信次数。 对这种情况，我们就可以利用外观模式，让后端服务器提供一个包裹 a、b、d 三个接口调用的接口 x。App 客户端调用一次接口 x，来获取到所有想要的数据，将网络通信的次数从 3 次减少到 1 次，也就提高了 App 的响应速度。

2. 外观模式的真实例子

2.1 背景

们很容易低估使用信用卡订购披萨时幕后工作的复杂程度。在整个过程中会有不少的子系统发挥作用。下面是其中的一部分：

• 检查账户
• 检查安全码
• 借记/贷记余额
• 账簿录入
• 发送消息通知

2.2 解决方案

在如此复杂的系统中，可以说是一步错步步错，很容易就会引发大的问题。

这就是为什么我们需要外观模式，让客户端可以使用一个简单的接口来处理众多组件。

客户端只需要输入卡片详情、安全码、支付金额以及操作类型即可。外观模式会与多种组件进一步地进行沟通，而又不会向客户端暴露其内部的复杂性。

3. 外观模式的应用场景

3.1 解决易用性问题

外观模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口。

设计原则、思想、模式很多都是相通的，是同一个道理不同角度的表述。实际上，从隐藏实现复杂性，提供更易用接口这个意图来看，外观模式有点类似之前讲到的迪米特法则（最少知识原则）和接口隔离原则：两个有交互的系统，只暴露有限的必要的接口。除此之外，外观模式还有点类似之前提到封装、抽象的设计思想，提供更抽象的接口，封装底层实现细节。

3.2 解决性能问题

我们通过将多个接口调用替换为一个外观接口调用，减少网络通信成本，提高 App 客户端的响应速度。

如果外观接口不多，我们完全可以将它跟非外观接口放到一块，也不需要特殊标记，当作普通接口来用即可。如果外观接口很多，我们可以在已有的接口之上，再重新抽象出一层，专门放置外观接口，从类、包的命名上跟原来的接口层做区分。如果外观接口特别多，并且很多都是跨多个子系统的，我们可以将外观接口放到一个新的子系统中。

4. 外观模式与适配模式

• 适配器是做接口转换，解决的是原接口和目标接口不匹配的问题。
• 门面模式做接口整合，解决的是多接口调用带来的问题。