外观模式通过门面类封装多个子系统，提供统一高层接口，降低客户端使用复杂度；门面以组合方式持有子系统引用，集中初始化、编排调用、转换异常、屏蔽细节，并隔离子系统变化，但需避免职责膨胀。
外观模式（Facade）通过提供一个统一的高层接口，把一组复杂的子系统调用封装起来，让客户端只需和这个“门面”交互，不用关心底层多个类如何协作。它不改变子系统功能，只降低使用门槛。
用一个门面类聚合多个子系统对象
把原本需要手动创建、协调的多个子系统实例（比如订单服务、库存服务、支付服务），在门面类内部完成初始化和依赖管理。客户端只需 new 一次门面，就能触发一整套流程。
- 门面类通常不继承子系统，而是以组合方式持有它们的引用
- 构造方法或初始化块中完成子系统对象的创建（也可配合依赖注入）
- 避免在门面方法里每次 new 子系统实例，防止资源浪费或状态丢失
把多步操作封装成单个简洁方法
例如用户下单，原本要分别调用库存校验 → 创建订单 → 扣减库存 → 发起支付 → 记录日志，现在只需调用 orderFacade.placeOrder(request) 一行代码。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 门面方法内部按业务逻辑顺序编排子系统调用，并处理中间结果传递
- 对异常做集中捕获和转换，比如把库存服务抛出的 InsufficientStockException 转为更上层的 BusinessException
- 可加入简单参数校验、默认值填充、DTO 转换等前置逻辑，进一步屏蔽细节
隔离变化，便于后续重构或替换子系统
当某个子系统升级接口、更换实现（比如从本地库存服务换成远程 HTTP 库存服务），只要新实现仍满足原有契约，门面类内部修改即可，所有调用方完全无感。
立即学习“Java免费学习笔记（深入）”；
- 门面定义的接口是稳定的，子系统接口变动不影响客户端代码
- 适合集成第三方 SDK、遗留系统或模块边界清晰但内部耦合高的场景
- 如果子系统本身已很轻量（如只有1–2个类），强行加门面反而增加冗余
注意别让门面变成“上帝类”
门面应聚焦于协调职责，而不是承担业务规则或数据处理。过度堆积逻辑会让它难以维护，也违背单一职责原则。
- 复杂校验、策略选择、状态机流转等应保留在独立的服务类中，门面只负责调度
- 避免在门面中直接操作数据库、发 HTTP 请求等具体实现，这些仍由对应子系统完成
- 必要时可提供多个门面（如 AdminFacade 和 UserFacade），按角色或场景划分职责
