gof-facade

一句话概述

为子系统中的一组接口提供统一、简化的接口，让子系统更易于使用，同时不妨碍高级用户直接访问。

何时使用此技能

• 子系统包含许多部分，而大多数调用方只需要对这些部分执行少量常见操作。
• 将新代码接入复杂代码库时，Facade 可为新代码提供一个简洁的入口。
• 封装内部复杂性不应到处暴露的旧版库或第三方库。
• 经典示例：“看电影” Facade 会打开电视、调暗灯光、放下幕布、将接收器切换到正确的输入源、安排爆米花机工作并启动 DVD，而不是让每个调用方都编排这些步骤。

何时不使用此技能

• 你想要替换子系统，而不是提供更简便的入口——这属于重构子系统。
• 你想要更改单个类的接口——这属于 gof-adapter。
• 子系统确实很小，Facade 只会徒增一层间接调用。
• 调用方确实需要子系统提供的完整控制能力；隐藏太多内容的 Facade 会迫使他们绕过它。

核心内容

Facade 是一个持有其所编排的子系统类引用，并公开少量高级方法的类。Facade 的每个方法都会将多个底层操作组合成一个整体，使其符合调用方关心的含义。

Facade 的核心原则：它不会阻止访问子系统。需要更精细控制的调用方仍可直接访问子系统。Facade 是为了方便，而不是一道屏障。

HFDP 与 Facade 相关联的原则是最少知识原则（迪米特法则）。Facade 方法只与少量紧密协作的对象交互，而不是从远处深入访问子系统。

决策启发

• Facade 方法应体现一种用户意图（“watchMovie”“shutdownProperly”“settleOrder”），而不是对某个子系统调用的简单转发。
• 尽可能让 Facade 本身保持无状态；它应负责编排，而不是拥有状态。
• 如果你发现自己在 Facade 中添加了许多 setter，它就不再是 Facade 了。

反模式

• 禁止直接访问子系统的 Facade——Facade 是为了方便，而不是一座堡垒。
• 为子系统的每个方法都提供一个名称相同的 Facade 方法——这只是转发，并非 Facade。
• 逐渐了解子系统所有细节的 Facade——到了一定程度，它就不再是“高级”接口，而会变成上帝类。
• 为同一子系统构建多个 Facade，各自提供略有不同的便利功能——这通常表明底层子系统需要重构。

另请参阅

• gof-adapter — 将一个类包装成不同接口时使用；Facade 则将多个类包装成更简单的接口。
• gof-mediator（此处未介绍，GoF 原版）— Facade 是单向的（调用方 → 子系统）；Mediator 则负责同级对象之间的双向协调。
• gof-kotlin-idioms — Kotlin 中的顶层函数和扩展函数通常可充当轻量级 Facade，无需创建类。

参考资料

• Head First Design Patterns（第 2 版），第 7 章（“灵活应变：适配器模式与外观模式”）——家庭影院示例是经典范例。