外观模式（Facade Pattern） 是一种 结构型设计模式 ，旨在为复杂的子系统提供一个统一的、简化的高层接口，使得客户端更容易使用子系统功能。它的核心思想是 隐藏系统复杂性，提供易用入口。
1. 核心角色
| 角色 | 说明 |
|---|---|
| 外观类（Facade） | 提供统一的接口，将客户端的请求转发到子系统中的适当对象。 |
| 子系统类（Subsystem Classes） | 实现子系统的具体功能，外观类通过组合这些类来完成任务。 |
2. 应用场景
-
简化复杂系统：当系统存在多个复杂模块或接口时，提供一个统一入口。
-
降低耦合度：减少客户端与子系统的直接依赖，提高系统可维护性。
-
分层架构：为不同层次的模块提供统一接口（如API网关）。
3. 代码示例：家庭影院控制系统
假设家庭影院包含多个设备（灯光、音响、投影仪），通过外观模式一键启动"观影模式"。
步骤1：定义子系统类 
步骤2：定义外观类（统一接口） 
步骤3：客户端调用 
输出结果 
4. 外观模式类图 
5. 外观模式优缺点
| 优点 | 缺点 |
|---|---|
| 简化客户端调用，隐藏系统复杂性。 | 可能引入单点故障（外观类成为瓶颈）。 |
| 降低客户端与子系统的耦合度。 | 违反开闭原则（修改子系统需调整外观类）。 |
| 提升代码可维护性和可读性。 |
6. 外观模式 vs. 中介者模式
| 模式 | 目的 | 关注点 |
|---|---|---|
| 外观模式 | 简化子系统接口，提供统一入口。 | 单向通信（外观调用子系统）。 |
| 中介者模式 | 协调多个对象间的交互，减少直接通信。 | 双向通信（对象间通过中介者交互）。 |
7. 实际应用场景
-
API 网关
-
外观类：网关统一处理鉴权、限流、路由。
-
子系统：多个微服务（订单、用户、支付）。
-
-
日志框架
-
外观类 ：
Logger接口（如 SLF4J）。 -
子系统：具体日志实现（Logback、Log4j2）。
-
-
文件压缩工具
-
外观类 ：提供
compress()和decompress()方法。 -
子系统：ZIP、RAR、7z 等压缩算法。
-
9. 总结
-
核心价值：通过封装复杂子系统，提供简洁易用的接口。
-
关键设计：外观类通过组合子系统对象，对外暴露统一方法。
-
适用性：当系统复杂度高且需要简化客户端调用时，优先选择外观模式。