香香甜甜圈1. 外观模式初探：为什么我们需要"门面"？
记得刚入行那会儿，我接手过一个电商支付系统改造项目。当时系统里有十几个模块互相调用：风控要查用户信用，账户要核对余额，支付网关要处理通道选择，通知服务要发短信邮件...每个模块的接口文档都有几十页。有天凌晨三点调试时，我对着满屏的API调用链突然意识到——要是能有个统一的入口该多好。这就是外观模式（Facade）最朴素的诞生场景。
外观模式属于结构型设计模式，它就像建筑的门面（Facade）一样，为复杂的子系统提供一个统一的高层接口。当你的系统存在以下特征时，就该考虑引入外观模式了：
- 子系统调用链路超过3层（比如A调B调C调D）
- 多个模块需要协同完成一个业务目标
- 客户端需要了解过多子系统细节
关键认知：外观模式不是简单的"封装"，而是通过建立合理的抽象层次，重新组织系统交互关系。就像酒店前台不会让客人直接联系保洁、厨师、维修工一样。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 模式结构解析：从UML到代码实现
2.1 经典UML类图拆解
用IntelliJ IDEA的Diagram功能生成的简化UML如下：
code复制+----------------+ +-------------------+
| Client | | Facade |
| |------>| |
+----------------+ +-------------------+
/ \
/ \
+----------------+ +----------------+
| SubSystem A | | SubSystem B |
| +operation1() | | +operation2() |
+----------------+ +----------------+
三个核心角色