门面模式

平衡接口粒度

接口粒度更细（职责单一）

1. 接口具有更好的可复用性
2. 接口的使用者开发一个业务功能时，需要调用 n 多细粒度的接口才能完成，调用者会抱怨接口不好用。

接口粒度设计得太大

1. 一个接口能做更多的事
2. 可复用性不好。那针对不同的业务需求，就需要开发不同的接口来满足，这就会导致系统的接口无限膨胀。

那如何来解决接口的可复用性（通用性）和易用性之间的矛盾呢？门面模式！

门面模式的原理和实现

定义

门面模式，也叫外观模式，英文全称是 Facade Design Pattern。它的定义如下：

门面模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用。

门面模式定义中的“子系统（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 三个接口，因自 身业务的特点，不支持并发调用这三个接口。

现在发现 App 客户端的响应速度比较慢，排查之后发现，是因为过多的接口调用过多的网络通信。针对这种情况，可以利用门面模式，让后端服务器提供一个包裹 a、b、d 三个接口调用的接口 x。App 客户端调用一次接口 x，来获取到所有想要的数据，将网络通信的次数从 3 次减少到 1 次，也就提高了 App 的响应速度。

常见应用场景

解决易用性问题

门面模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口。比如，Linux 的 Shell 命令，实际上也可以看作一种门面模式的应用。它继续封装系统调用，提供更加友好、简单的命令，让我们可以直接通过执行命令来跟操作系统交互。

解决性能问题

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

解决分布式事务问题

在一个金融系统中，有两个业务领域模型，用户和钱包。假设有这样一个业务场景：在用户注册的时候，我们不仅会创建用户（在数据库User表中），还会给用户创建一个钱包（在数据库的 Wallet 表中）。

显然用户注册需要支持事务，即创建用户和钱包的两个操作，要么都成功，要么都失败。

然后两个不同服务的接口调用在同一个事务中执行比较难实现，这涉及到分布式事务问题，虽然可以通过引入分布式事务框架或者事后补偿的机制来解决，但代码实现都比较复杂。而最简单的解决方案是，利用数据库事务或者 Spring 框架提供的事务（如果是 Java 语言的话），在一个事务中，执行创建用户和创建钱包这两个 SQL 操作。这就要求两个 SQL 操作要在一个接口中完成，所以，我们可以借鉴门面模式的思想，再设计一个包裹这两个操作的新接口，让新接口在一个事务中执行两个 SQL 操作。