第十章 门面模式
门面模式（Facade Pattern）是一种结构型设计模式，旨在提供一个简化的接口，以便客户端能够更容易地与复杂系统进行交互。这种模式允许客户端通过与一个高层次的接口（门面）交互，而无需了解系统内部的复杂性。
门面模式的主要目标是封装一个复杂的子系统，以提供一个更简单和更高层次的接口，使客户端能够更容易地使用系统。这有助于降低系统的复杂性，并提高了系统的可维护性和可扩展性。
以下是门面模式的关键要点和示例：
关键要点：
门面类（Facade）： 门面类是门面模式的核心，它提供了一个简单的接口，封装了系统内部的复杂子系统。客户端通过与门面类交互来访问系统功能，而不必了解系统内部的细节。
子系统（Subsystems）： 子系统是系统内部的各个模块或类，它们负责执行系统的具体功能。门面类将这些子系统组织起来，并提供一个统一的接口。
客户端（Client）： 客户端是使用门面模式的代码部分，它通过与门面类交互来实现系统功能，而不需要与子系统直接交互。
门面模式示例：
考虑一个多媒体播放器应用程序的示例，其中包含音频播放、视频播放和文件管理等多个子系统。客户端想要播放音频文件，但不希望了解音频解码、声音调整等复杂细节。这时，可以使用门面模式来简化客户端与多媒体播放器之间的交互。
以下是一个简化的 Java 示例：
// 子系统 - 音频播放器
class AudioPlayer {
void play(String audioFile) {
System.out.println("Playing audio: " + audioFile);
}
}
// 子系统 - 视频播放器
class VideoPlayer {
void play(String videoFile) {
System.out.println("Playing video: " + videoFile);
}
}
// 子系统 - 文件管理器
class FileManager {
void openFile(String fileName) {
System.out.println("Opening file: " + fileName);
}
}
// 门面类 - 多媒体播放器门面
class MultimediaPlayerFacade {
private AudioPlayer audioPlayer;
private VideoPlayer videoPlayer;
private FileManager fileManager;
public MultimediaPlayerFacade() {
this.audioPlayer = new AudioPlayer();
this.videoPlayer = new VideoPlayer();
this.fileManager = new FileManager();
}
// 提供一个简单接口，封装了多媒体播放功能
public void playAudio(String audioFile) {
audioPlayer.play(audioFile);
}
public void playVideo(String videoFile) {
videoPlayer.play(videoFile);
}
public void openFile(String fileName) {
fileManager.openFile(fileName);
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
MultimediaPlayerFacade player = new MultimediaPlayerFacade();
player.playAudio("music.mp3");
player.playVideo("movie.mp4");
player.openFile("document.pdf");
}
}
在这个示例中，MultimediaPlayerFacade 是门面类，它封装了音频播放、视频播放和文件管理的子系统。客户端代码通过与门面类交互来实现多媒体播放和文件管理，而不需要了解子系统内部的复杂性。这种方式使客户端代码更简洁和易于维护。门面模式的好处在于，它隐藏了系统内部的复杂性，提供了一个清晰、高层次的接口，使客户端更容易使用系统功能。
面模式。门面模式原理和实现都特别简单，应用场景也比较明确，主要在接口设计方面使用。
如果你平时的工作涉及接口开发，不知道你有没有遇到关于接口粒度的问题呢？
为了保证接口的可复用性（或者叫通用性），我们需要将接口尽量设计得细粒度一点，职责单一一点。但是，如果接口的粒度过小，在接口的使用者开发一个业务功能时，就会导致需要调用 n 多细粒度的接口才能完成。调用者肯定会抱怨接口不好用。
相反，如果接口粒度设计得太大，一个接口返回 n 多数据，要做 n 多事情，就会导致接口不够通用、可复用性不好。接口不可复用，那针对不同的调用者的业务需求，我们就需要开发不同的接口来满足，这就会导致系统的接口无限膨胀。
那如何来解决接口的可复用性（通用性）和易用性之间的矛盾呢？通过今天对于门面模式的学习，我想你心中会有答案。
1. 门面模式的原理与实现
门面模式，也叫外观模式，英文全称是 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 与服务器之间的网络通信次数。
这里举的例子只是应用门面模式的其中一个意图，也就是解决性能问题。实际上，不同的应用场景下，使用门面模式的意图也不同。接下来，我们就来看一下门面模式的各种应用场景。
1.1 门面模式的应用场景举例
在 GoF 给出的定义中提到，“门面模式让子系统更加易用”，实际上，它除了解决易用性问题之外，还能解决其他很多方面的问题。关于这一点，我总结罗列了 3 个常用的应用场景，你可以参考一下，举一反三地借鉴到自己的项目中。
除此之外，我还要强调一下，门面模式定义中的“子系统（subsystem）”也可以有多种理解方式。它既可以是一个完整的系统，也可以是更细粒度的类或者模块。关于这一点，在下面的讲解中也会有体现。
1.2 解决易用性问题
门面模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口。比如，Linux 系统调用函数就可以看作一种“门面”。它是 Linux 操作系统暴露给开发者的一组“特殊”的编程接口，它封装了底层更基础的 Linux 内核调用。再比如，Linux 的 Shell 命令，实际上也可以看作一种门面模式的应用。它继续封装系统调用，提供更加友好、简单的命令，让我们可以直接通过执行命令来跟操作系统交互。
我们前面也多次讲过，设计原则、思想、模式很多都是相通的，是同一个道理不同角度的表述。实际上，从隐藏实现复杂性，提供更易用接口这个意图来看，门面模式有点类似之前讲到的迪米特法则（最少知识原则）和接口隔离原则：两个有交互的系统，只暴露有限的必要的接口。除此之外，门面模式还有点类似之前提到封装、抽象的设计思想，提供更抽象的接口，封装底层实现细节。
1.3 解决性能问题
关于利用门面模式解决性能问题这一点，刚刚我们已经讲过了。我们通过将多个接口调用替换为一个门面接口调用，减少网络通信成本，提高 App 客户端的响应速度。所以，关于这点，我就不再举例说明了。我们来讨论一下这样一个问题：从代码实现的角度来看，该如何组织门面接口和非门面接口？
如果门面接口不多，我们完全可以将它跟非门面接口放到一块，也不需要特殊标记，当作普通接口来用即可。如果门面接口很多，我们可以在已有的接口之上，再重新抽象出一层，专门放置门面接口，从类、包的命名上跟原来的接口层做区分。如果门面接口特别多，并且很多都是跨多个子系统的，我们可以将门面接口放到一个新的子系统中。
1.4 解决分布式事务问题
关于利用门面模式来解决分布式事务问题，我们通过一个例子来解释一下。
在一个金融系统中，有两个业务领域模型，用户和钱包。这两个业务领域模型都对外暴露了一系列接口，比如用户的增删改查接口、钱包的增删改查接口。
假设有这样一个业务场景：在用户注册的时候，我们不仅会创建用户（在数据库 User 表中），还会给用户创建一个钱包（在数据库的 Wallet 表中）。
对于这样一个简单的业务需求，我们可以通过依次调用用户的创建接口和钱包的创建接口来完成。但是，用户注册需要支持事务，也就是说，创建用户和钱包的两个操作，要么都成功，要么都失败，不能一个成功、一个失败。要支持两个接口调用在一个事务中执行，是比较难实现的，这涉及分布式事务问题。虽然我
们可以通过引入分布式事务框架或者事后补偿的机制来解决，但代码实现都比较复杂。而最简单的解决方案是，利用数据库事务或者 Spring 框架提供的事务（如果是 Java 语言的话），在一个事务中，执行创建用户和创建钱包这两个 SQL 操作。这就要求两个 SQL 操作要在一个接口中完成，所以，我们可以借鉴门面模式的思想，再设计一个包裹这两个操作的新接口，让新接口在一个事务中执行两个 SQL 操作。
