外观模式:简化复杂系统接口的设计模式
外观模式:简化复杂系统接口的设计模式
一、模式核心:为复杂子系统提供统一简单接口
当一个系统由多个复杂子系统组成时(如电商系统中的支付、物流、库存模块),客户端直接调用子系统会导致依赖关系复杂、代码难以维护。
外观模式(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 对象替代真实子系统)。