门面模式原理和实现很简单，应用场景也比较明确，主要在接口设计方面使用。通常为了保证接口的可复用性（或者叫通用性），我们需要将接口尽量设计得细粒度一点，职责单一一点。但如果接口的粒度过小，接口的使用方可能需要调用 n 多细粒度的接口才能完成工作，这对使用方来说不友好。而接口粒度设计得太大，一个接口做 n 多事情，就会导致接口不够通用、可复用性不好。那针对不同的调用者的业务需求，我们就需要开发不同的接口来满足，这就会导致系统的接口无限膨胀。

门面模式就是用来解决接口的可复用性（通用性）和易用性之间的矛盾问题。在实际的开发中，接口的可复用性和易用性需要“微妙”的权衡。针对这个问题的基本处理原则是，尽量保持接口的可复用性，但针对特殊情况，允许提供冗余的门面接口，来提供更易用的接口。

门面模式的原理与实现

门面模式，也叫外观模式，英文全称是 Facade Design Pattern。在 GoF 的《设计模式》一书中，门面模式是这样定义的：

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.

翻译成中文就是：门面模式为子系统提供一组统一的高层接口，用来访问子系统中的一群接口，目的是让子系统更容易使用。

举个例子，假设有一个系统 A，提供了 a、b、c、d 四个接口。系统 B 完成某个业务功能，需要调用 A 系统的 a、b、d 接口。利用门面模式，我们可以提供一个包裹 a、b、d 接口调用的门面接口 x 给系统 B 直接使用。

你可能有疑问，让系统 B 直接调用 a、b、d 感觉没有太大问题，为什么要提供一个包裹 a、b、d 的接口 x 呢？假设我们刚刚提到的系统 A 是一个后端服务器，系统 B 是 App 客户端。App 客户端通过后端服务器提供的接口来获取数据。我们知道，App 和服务器之间是通过网络通信的，网络通信耗时比较多，为了提高 App 的响应速度，我们要尽量减少 App 与服务器之间的网络通信次数。

假设，App 客户端的某个页面信息展示需要“依次”调用 a、b、d 三个接口，但因自身业务的特点，不支持并发调用这三个接口。而为了能尽量减少网络通信，我们就可以利用门面模式，让后端服务器提供一个包裹 a、b、d 三个接口调用的接口 x。App 客户端调用一次接口 x 来获取到所有想要的数据，将网络通信的次数从 3 次减少到 1 次，也就提高了 App 的响应速度。

门面模式的应用场景

在 GoF 给出的定义中提到，“门面模式让子系统更加易用”，实际上，它除了解决易用性问题外，还能解决其他很多方面的问题。此外，我还要强调一下，门面模式定义中的“子系统”也可以有多种理解方式。它既可以是一个完整的系统，也可以是更细粒度的类或者模块。

1）解决易用性问题
门面模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口。Linux 系统调用函数就可以看作一种“门面”。它是 Linux 操作系统暴露给开发者的一组“特殊”的编程接口，它封装了底层更基础的 Linux 内核调用。

实际上，从隐藏实现复杂性，提供更易用接口这个意图来看，门面模式有点类似迪米特法则（最少知识原则）和接口隔离原则：两个有交互的系统，只暴露有限的必要的接口。除此之外，门面模式还有点类似面向对象封装、抽象的设计思想，提供更抽象的接口，封装底层实现细节。

2）解决性能问题
上面讲到，我们通过将多个接口调用替换为一个门面接口调用，减少网络通信成本，提高 App 客户端的响应速度。现在，我们来讨论一下这样一个问题：从代码实现的角度来看，该如何组织门面接口和非门面接口？

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

适配器模式与门面模式的区别

适配器模式和门面模式的共同点是，将不好用的接口适配成好用的接口。那他们之间有什么区别吗？

• 当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器模式；当需要简化并统一一个很大的接口或者一群复杂的接口时，使用门面模式。
• 适配器改变接口以符合客户的期望；门面将客户从一个复杂的子系统中解耦。
• 适配器将一个对象包装起来以改变其接口；装饰者将一个对象包装起来以增加新的行为和责任；而门面则将一群对象包装起来以简化其接口。