外观模式：简化复杂系统接口的设计模式
一、模式核心：为复杂子系统提供统一简单接口
当一个系统由多个复杂子系统组成时（如电商系统中的支付、物流、库存模块），客户端直接调用子系统会导致依赖关系复杂、代码难以维护。
外观模式（Facade Pattern） 通过引入一个外观类（Facade），将子系统的复杂接口封装为一个简单的统一接口，客户端只需与外观类交互，无需了解子系统的内部细节。核心解决：
- 解耦客户端与子系统：降低客户端对多个子系统的直接依赖，简化调用流程。
- 隐藏系统复杂性：将子系统的交互细节封装在外观类中，提供清晰易用的高层接口。
- 分层设计支持：在架构中划分层次（如门面层、服务层），符合迪米特法则（最少知识原则）。
核心思想与 UML 类图
外观模式包含以下角色：
- 外观类（Facade）：定义客户端调用的简单接口，内部调用子系统的功能。
- 子系统类（Subsystem Classes）：实现系统的具体功能，相互之间可能有复杂交互。
- 客户端（Client）：通过外观类间接使用子系统功能。
二、核心实现：电商下单流程的外观封装
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 对象替代真实子系统）。
