外观模式的核心是封装高频、有业务含义的子系统操作组合，按固定顺序协调已有方法，不新增逻辑，接口简洁，客户端无需接触子系统细节。

直接用外观模式给复杂子系统“减负”，关键不是多写一个类，而是把客户端真正要做的事，打包成一句能懂的话。

找准高频、有业务含义的操作组合

别一上来就建 Facade 类。先看客户端每次完成一件事，到底得调哪些子系统、按什么顺序。比如“启动家庭影院”，实际是关灯→拉窗帘→开投影→调音响→播放影片。这些步骤就是外观该封装的内核。只包那些反复出现、逻辑连贯的动作，像调试用的单次调用或纯工具方法，就不该塞进去。

• 打开日志、初始化缓存、加载配置、启动播放器——如果这四步总是一起出现，就该归到一个 playVideo() 里
• 下单流程里，“查库存→锁库存→创建订单→发起支付→发物流通知”，顺序不能乱，外观正好管这个
• 避免把子系统所有 public 方法都搬到 Facade 上，接口越少越清晰

外观类只做协调，不新增逻辑

Facade 不是新业务层，它不处理校验、不计算折扣、不拼接字符串。它只负责按正确顺序，把已有子系统的已有方法串起来。就像乐队指挥，不演奏乐器，但确保小提琴先起、鼓点跟上、长笛收尾。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 构造器里只注入真正用到的子系统实例，比如 OrderFacade 只需 InventoryService 和 PaymentService，不必引入 LogService（除非日志是业务必需环节）
• 方法名用动宾短语，如 placeOrder()、shutDownTheater()，不用 doProcess() 或 handleRequest()
• 内部不加 if-else 分支做新判断，也不调用未声明依赖的类

让客户端彻底远离子系统细节

一旦有了外观，客户端代码里就不该再出现任何子系统类名。电视、音响、投影仪这些类型，对调用方来说应该“看不见”。

• 把子系统类设为 package-private（默认访问权限），从编译层面堵住直连路径
• Spring 环境下用 @Service 声明 Facade，并通过接口注入，禁止 new 实例
• 单元测试时，用 Mockito 模拟子系统，验证 Facade 是否按预期顺序调用了正确方法，而不是去测子系统本身是否工作

预留扩展性，别把它写死

外观是门面，不是牢笼。当子系统加了新能力，比如音响支持杜比音效，外观不该重写，而应提供新方法如 watchMovieWithDolby()，或在原有方法里加可选参数。

• 避免把所有流程硬编码在单一方法里，可考虑用策略或模板方法支持变体流程
• 如果多个场景共用部分步骤（如“影院模式”和“游戏模式”都需关灯、调亮度），可提取公共子流程，再由不同外观组合调用
• 对外暴露的接口保持稳定，内部实现可随子系统升级灵活调整

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南