门面设计模式
门面模式
门面设计模式是一种结构设计模式，它为复杂的子系统提供了统一、简化的界面，使客户更容易与多个组件进行交互，而不会被它们的复杂性所淹没。
它在以下情况下特别有用：
您的系统包含许多相互依赖的类或低级 API。
客户不需要知道这些部分在内部是如何工作的。
您希望减少客户端和复杂系统之间的学习曲线或耦合。
在构建应用程序时，您通常需要与多个组件进行交互才能实现单个任务。
例如，部署新版本的应用可能需要按特定顺序调用构建系统、容器服务、监控工具和通知系统。
您可以在每个客户端类中编写此逻辑，但它很快就会变得容易出错、重复，并且与每个子系统的内部细节紧密耦合。
Facade Pattern 通过引入单个入口点（门面）解决了这个问题，该入口将复杂的交互包裹在一个干净且易于使用的界面后面。
这使您的客户端代码保持简单、解耦，并且只专注于它需要做的事情。
让我们通过一个真实世界的示例，看看如何应用 Facade Pattern 来隐藏复杂性并提高可维护性。
问题：部署复杂性
假设您正在 为开发团队构建一个部署自动化工具。
从表面上看，部署应用程序似乎是一项简单的任务，但实际上，它涉及一系列协调的、容易出错的步骤。
下面是典型部署流的简化版本：
从 Git 存储库中提取最新代码
使用 Maven 或 Gradle 等工具构建项目
运行自动化测试（单元测试、集成测试，也许是端到端测试）
将生成部署到生产环境
这些步骤中的每一个都可能由单独的模块或类处理，每个模块或类都有自己特定的 API 和配置。
部署子系统
- 1. 版本控制系统
public class VersionControlSystem {public void pullLatestChanges(String branch) {System.out.println("VCS: Pulling latest changes from '" + branch + "'...");simulateDelay();System.out.println("VCS: Pull complete.");}private void simulateDelay() {try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}}
}处理与 Git 或其他 VCS 的交互。负责获取最新代码。
- 2. 构建系统
public class BuildSystem {public boolean compileProject() {System.out.println("BuildSystem: Compiling project...");simulateDelay(2000);System.out.println("BuildSystem: Build successful.");return true;}public String getArtifactPath() {String path = "target/myapplication-1.0.jar";System.out.println("BuildSystem: Artifact located at " + path);return path;}private void simulateDelay(int ms) {try {Thread.sleep(ms);} catch (InterruptedException e) {e.printStackTrace();}}
}编译代码库，创建一个项目（如 ），并返回其位置。.jar
- 3. 测试框架
public class TestingFramework {public boolean runUnitTests() {System.out.println("Testing: Running unit tests...");simulateDelay(1500);System.out.println("Testing: Unit tests passed.");return true;}public boolean runIntegrationTests() {System.out.println("Testing: Running integration tests...");simulateDelay(3000);System.out.println("Testing: Integration tests passed.");return true;}private void simulateDelay(int ms) {try {Thread.sleep(ms);} catch (InterruptedException e) {e.printStackTrace();}}
}执行单元测试和集成测试。还可能包括 E2E、突变测试或实际设置中的安全扫描。
- 4. 部署目标
public class DeploymentTarget {public void transferArtifact(String artifactPath, String server) {System.out.println("Deployment: Transferring " + artifactPath + " to " + server + "...");simulateDelay(1000);System.out.println("Deployment: Transfer complete.");}public void activateNewVersion(String server) {System.out.println("Deployment: Activating new version on " + server + "...");simulateDelay(500);System.out.println("Deployment: Now live on " + server + "!");}private void simulateDelay(int ms) {try {Thread.sleep(ms);} catch (InterruptedException e) {e.printStackTrace();}}
}处理到服务器的工件交付和版本激活。
The Orchestrator
是 试图协调一切的组件。它拉入所有子系统并定义执行部署的确切作顺序。DeploymentOrchestrator
public class DeploymentOrchestrator {private VersionControlSystem vcs = new VersionControlSystem();private BuildSystem buildSystem = new BuildSystem();private TestingFramework testFramework = new TestingFramework();private DeploymentTarget deployTarget = new DeploymentTarget();public boolean deployApplication(String branch, String prodServer) {System.out.println("\n[Orchestrator] Starting deployment for branch: " + branch);vcs.pullLatestChanges(branch);if (!buildSystem.compileProject()) {System.err.println("Build failed. Deployment aborted.");return false;}String artifact = buildSystem.getArtifactPath();if (!testFramework.runUnitTests() || !testFramework.runIntegrationTests()) {System.err.println("Tests failed. Deployment aborted.");return false;}deployTarget.transferArtifact(artifact, prodServer);deployTarget.activateNewVersion(prodServer);System.out.println("[Orchestrator] Deployment successful!");return true;}
}使用 Orchestrator
public class DeploymentAppDirect {public static void main(String[] args) {DeploymentOrchestrator orchestrator = new DeploymentOrchestrator();orchestrator.deployApplication("main", "prod.server.example.com");System.out.println("\n--- Attempting another deployment ---");orchestrator.deployApplication("feature/new-ui", "staging.server.example.com");}
}这个设计有什么问题？
虽然业务流程逻辑有效，但随着系统的增长，它会导致几个主要问题：
- 1. 客户端复杂性高
本 质上充当您的“客户端”的 — 必须了解每个子系统：DeploymentOrchestrator
调用什么方法
以什么顺序
成功或失败时该怎么做
这会使客户的责任膨胀，并将其与系统的内部运作紧密耦合。
- 2. 子系统之间的紧密耦合
每个子系统（VCS、构建、测试、部署）都直接从编排器调用。其中任何一个子系统的更改（例如， 现在采用环境标志）都会在编排器中产生涟漪，并可能波及使用它的所有其他地方。compileProject() - 3. 可维护性差
想要：
添加代码质量扫描？
部署后发送 Slack 通知？
集成回滚机制？
您每次都需要更新业务流程协调程序 — 用更多的逻辑和责任使其膨胀，违反了单一责任原则。 - 4. 分散的工作流程逻辑
如果系统的其他部分（例如，Webhook 处理程序或 CI 触发器）需要执行部署：
您要么在其他地方复制逻辑（增加不一致的可能性），要么
您重用编排器，它已经变得单体和僵化。
我们需要什么
我们需要一种方法来：
隐藏底层子系统的复杂性
公开一个简单统一的界面来执行部署
将客户端代码与内部工作流分离
使系统更易于维护、测试和发展
这正是门面图案适合的地方。
门面设计模式
Facade Pattern 引入了一个高级接口，该接口隐藏了一个或多个子系统的复杂性，并仅公开客户端所需的功能。
类图
它的工作原理如下：
门面（例如 DeploymentFacade)
知道 要使用哪些子系统类以及按什么顺序使用。将请求委托给适当的子系统方法，而不向客户端公开内部详细信息。
子系统类（例如，： VersionControlSystemBuildSystem)
提供处理特定任务的实际业务逻辑。 不知道门面。如果需要，仍然可以独立使用。
客户端（例如，我们的主要应用程序或脚本）：
使用 Facade 启动部署，而不是直接与子系统类交互。
现实世界的类比
想想一家高端酒店。作为客人（客户），您不想单独联系客房服务部门以获取干净的毛巾、餐厅预订晚餐以及代客泊车。相反，您致电礼宾服务台（Facade）。
你向礼宾部提出一个简单的要求，比如“我想在晚上 8 点预订晚餐，然后准备好我的车。然后，礼宾部与所有必要的酒店部门（子系统）互动以满足您的要求。
作为客人，您免受这种内部复杂性的影响。礼宾服务台为酒店服务提供了一个简化的界面。
实现 Facade
Facade 类（在我们的例子中） 充当 应用程序部署中涉及的一组复杂作的单一统一接口。DeploymentFacade
在内部，它包含对部署管道的核心构建基块的引用：
VersionControlSystem– 从 Git 分支获取最新代码
BuildSystem– 编译代码并生成可部署的工件
TestingFramework– 运行自动化测试（单元、集成）
DeploymentTarget– 传输工件并在目标服务器上激活它
门面不是强制客户端以正确的顺序调用每个子系统，而是抽象了这种协调逻辑，并提供了一个干净的高级方法，就像 执行整个工作流一样。deployApplication()
public class DeploymentFacade {// Instances of all the subsystem components// or they can be injected (e.g., via constructor for better testability).private VersionControlSystem vcs = new VersionControlSystem();private BuildSystem buildSystem = new BuildSystem();private TestingFramework testingFramework = new TestingFramework();private DeploymentTarget deploymentTarget = new DeploymentTarget();// Perform a full standard deployment: pull, build, test, deploy.public boolean deployApplication(String branch, String serverAddress) {System.out.println("\nFACADE: --- Initiating FULL DEPLOYMENT for branch: " + branch + " to " + serverAddress + " ---");boolean success = true;try {// Step 1: Pull latest codevcs.pullLatestChanges(branch);// Step 2: Build the projectif (!buildSystem.compileProject()) {System.err.println("FACADE: DEPLOYMENT FAILED - Build compilation failed.");return false; // Exit early on critical failure}String artifactPath = buildSystem.getArtifactPath();// Step 3: Run testsif (!testingFramework.runUnitTests()) {System.err.println("FACADE: DEPLOYMENT FAILED - Unit tests failed.");return false;}if (!testingFramework.runIntegrationTests()) {System.err.println("FACADE: DEPLOYMENT FAILED - Integration tests failed.");return false;}// Step 4: Deploy to productiondeploymentTarget.transferArtifact(artifactPath, serverAddress);deploymentTarget.activateNewVersion(serverAddress);System.out.println("FACADE: APPLICATION DEPLOYED SUCCESSFULLY TO " + serverAddress + "!");} catch (Exception e) {System.err.println("FACADE: DEPLOYMENT FAILED - An unexpected error occurred: " + e.getMessage());e.printStackTrace(); // Log the full stack tracesuccess = false;}return success;}public boolean deployHotfix(String branch, String serverAddress) {System.out.println("\nFACADE: --- Initiating HOTFIX DEPLOYMENT for branch: " + branch + " to " + serverAddress + " ---");boolean success = true;try {// Step 1: Pull latest codevcs.pullLatestChanges(branch);// Step 2: Build the projectif (!buildSystem.compileProject()) {System.err.println("FACADE: HOTFIX FAILED - Build compilation failed.");return false;}String artifactPath = buildSystem.getArtifactPath();// Step 3: For a hotfix, we might skip extensive tests or run a specific "smoke test" suite.System.out.println("FACADE: Skipping full test suite for hotfix deployment (or running minimal smoke tests).");// if (!testingFramework.runSmokeTests()) { return false; } // Example// Step 4: Deploy to productiondeploymentTarget.transferArtifact(artifactPath, serverAddress);deploymentTarget.activateNewVersion(serverAddress);System.out.println("FACADE: HOTFIX DEPLOYED SUCCESSFULLY TO " + serverAddress + "!");} catch (Exception e) {System.err.println("FACADE: HOTFIX FAILED - An unexpected error occurred: " + e.getMessage());success = false;}return success;}// We could add other simplified methods: rollbackLastDeployment(), checkDeploymentStatus(), etc.
}感谢门面：
客户端不再需要理解单个子系统或与之交互。
它不需要担心作顺序、错误处理或内部逻辑。
它只是调用一种表达方法：。deployApplication()
使用客户端的外观
public class DeploymentAppFacade {public static void main(String[] args) {DeploymentFacade deploymentFacade = new DeploymentFacade();// Deploy to productiondeploymentFacade.deployApplication("main", "prod.server.example.com");// Deploy a feature branch to stagingSystem.out.println("\n--- Deploying feature branch to staging ---");deploymentFacade.deployApplication("feature/new-ui", "staging.server.example.com");}
}简单、可读且可维护。客户不知道（或关心）涉及多少活动部件——只是部署有效。
不断发展系统：客户端不做任何改变
Facade Pattern 最强大的方面之一是它如何将客户端代码与内部更改隔离开来。
假设明天我们需要添加：
deployHotfix(branch, server)
rollbackLastDeployment(server)
checkDeploymentStatus(server)
您可以在幕后实现逻辑（例如，通过引入 、 等新类），并将它们作为新方法公开在 ：DeploymentHistoryManagerStatusCheckerDeploymentFacade
客户端代码保持完全不变。
要使用新功能，客户端代码可以调用 Facade 中的相关方法：
deploymentFacade.deployHotfix("hotfix/urgent-patch", "prod.server.example.com");
deploymentFacade.rollbackLastDeployment("prod.server.example.com");
deploymentFacade.checkDeploymentStatus("staging.server.example.com");其他阅读材料：
https://pan.baidu.com/s/1c1oQItiA7nZxz8Rnl3STpw?pwd=yftc
https://pan.quark.cn/s/dec9e4868381