外观模式：简化复杂系统接口的设计模式

一、模式核心：为复杂子系统提供统一简单接口

当一个系统由多个复杂子系统组成时（如电商系统中的支付、物流、库存模块），客户端直接调用子系统会导致依赖关系复杂、代码难以维护。

外观模式（Facade Pattern） 通过引入一个外观类（Facade），将子系统的复杂接口封装为一个简单的统一接口，客户端只需与外观类交互，无需了解子系统的内部细节。核心解决：

解耦客户端与子系统：降低客户端对多个子系统的直接依赖，简化调用流程。
隐藏系统复杂性：将子系统的交互细节封装在外观类中，提供清晰易用的高层接口。
分层设计支持：在架构中划分层次（如门面层、服务层），符合迪米特法则（最少知识原则）。

核心思想与 UML 类图

外观模式包含以下角色：

外观类（Facade）：定义客户端调用的简单接口，内部调用子系统的功能。
子系统类（Subsystem Classes）：实现系统的具体功能，相互之间可能有复杂交互。
客户端（Client）：通过外观类间接使用子系统功能。

PlantUML Diagram

二、核心实现：电商下单流程的外观封装

1. 定义子系统（支付、物流、库存）

支付模块

public class PaymentSystem {  public void processPayment(double amount) {  System.out.println("支付模块：处理支付，金额 " + amount + " 元");  }  
}

物流模块

public class LogisticsSystem {  public void shipOrder(String address) {  System.out.println("物流模块：发货至地址 " + address);  }  
}

库存模块

public class InventorySystem {  public boolean checkStock(int productId) {  System.out.println("库存模块：检查商品 " + productId + " 库存");  return true; // 假设库存充足  }  public void deductStock(int productId, int quantity) {  System.out.println("库存模块：扣除商品 " + productId + " 库存 " + quantity + " 件");  }  
}

2. 实现外观类（电商门面）

public class ECommerceFacade {  private PaymentSystem paymentSystem = new PaymentSystem();  private LogisticsSystem logisticsSystem = new LogisticsSystem();  private InventorySystem inventorySystem = new InventorySystem();  // 统一下单接口，封装三个子系统调用  public void placeOrder(int productId, int quantity, double price, String address) {  // 1. 检查库存  if (!inventorySystem.checkStock(productId)) {  System.out.println("下单失败：库存不足");  return;  }  // 2. 扣除库存  inventorySystem.deductStock(productId, quantity);  // 3. 处理支付  double totalAmount = price * quantity;  paymentSystem.processPayment(totalAmount);  // 4. 安排发货  logisticsSystem.shipOrder(address);  System.out.println("下单成功！");  }  
}

3. 客户端通过外观类下单

public class ClientDemo {  public static void main(String[] args) {  ECommerceFacade facade = new ECommerceFacade();  // 只需调用外观类的统一接口，无需了解子系统细节  facade.placeOrder(  productId = 1001,  quantity = 2,  price = 99.9,  address = "北京市朝阳区 XX 路"  );  }  
}

输出结果：

库存模块：检查商品 1001 库存  
库存模块：扣除商品 1001 库存 2 件  
支付模块：处理支付，金额 199.8 元  
物流模块：发货至地址 北京市朝阳区 XX 路  
下单成功！

三、进阶：外观模式与适配器模式结合

当子系统接口与外观接口不兼容时，可通过适配器模式转换接口，使外观类能适配不同子系统。

1. 定义旧版支付接口（需适配）

public class LegacyPaymentSystem {  public void pay(double amount, String method) {  System.out.println("旧版支付：使用 " + method + " 支付 " + amount + " 元");  }  
}

2. 实现适配器类

public class PaymentAdapter extends PaymentSystem {  private LegacyPaymentSystem legacySystem = new LegacyPaymentSystem();  @Override  public void processPayment(double amount) {  legacySystem.pay(amount, "支付宝"); // 适配旧版接口  }  
}

3. 修改外观类以支持适配器

public class ECommerceFacade {  private PaymentSystem paymentSystem = new PaymentAdapter(); // 使用适配器  // ... 其他代码不变 ...  
}

四、框架与源码中的外观实践

1. Spring MVC 的 DispatcherServlet

Spring MVC 通过 DispatcherServlet 作为外观类，统一处理客户端请求，调用控制器、模型、视图等子模块，隐藏请求分发、参数解析等细节。

2. AWT/Swing 的图形界面封装

Java 图形库通过外观类（如 JFrame、JPanel）封装底层操作系统的图形接口，实现跨平台的统一界面展示。

3. MyBatis 的 SqlSession

MyBatis 的 SqlSession 作为外观接口，封装了连接获取、SQL 执行、结果映射等子系统操作，客户端只需调用简单方法（如 selectOne()）即可完成数据库操作。

五、避坑指南：正确使用外观模式的 3 个要点

1. 避免外观类成为万能接口

外观类应聚焦于封装 “高频组合操作”，而非包含所有子系统功能。若外观类过于臃肿，可拆分为多个专用外观类（如订单外观、支付外观）。

2. 保留对子系统的直接访问

外观模式不强制客户端只能通过外观类访问子系统。若客户端需要细粒度控制，仍可直接调用子系统接口（如复杂业务场景下绕过外观类）。

3. 区分外观模式与中介者模式

外观模式：简化接口，不涉及子系统间的交互协调（子系统间可直接调用）。
中介者模式：解耦子系统，所有交互通过中介者完成（子系统间不直接通信）。

六、总结：何时该用外观模式？

适用场景	核心特征	典型案例
复杂系统对外接口	系统由多个子系统组成，需提供简单入口	微服务网关、系统集成平台
旧系统迁移	封装旧系统接口，适配新系统需求	遗留系统对接、第三方服务集成
分层架构设计	划分门面层与业务层，降低层间耦合	MVC 模式中的控制器层、DDD 中的应用层

外观模式通过 “统一接口 + 隐藏细节” 的设计，显著提升了系统的易用性和可维护性。下一篇我们将探讨备忘录模式，解析如何实现对象状态的撤销与恢复，敬请期待！

扩展思考：外观模式的优点

提高开发效率：客户端无需了解子系统细节，只需调用外观接口，缩短开发周期。
增强可测试性：通过外观类模拟子系统行为，便于单元测试（如使用 Mock 对象替代真实子系统）。

外观模式：简化复杂系统接口的设计模式