外观模式
软件工程中的经典结构型设计模式，通过在复杂子系统之上提供简化接口，隐藏内部实现细节，降低调用方与子系统的耦合度，特别适用于第三方库集成、分层架构和遗留系统封装场景
时间轴 (近 90 天)
外观模式（Facade Pattern）是四人帮（Gang of Four）在1994年《设计模式》一书中归纳的23种经典设计模式之一，属于结构型模式
外观模式的核心思路是在复杂系统之上建立一个简化的接口，让业务逻辑不必直接面对底层复杂性
外观并不阻止调用方绕过它直接访问子系统，它提供的是便利而非强制封装
外观模式不只是简化调用，更重要的是作为一道边界，决定哪些信息可以越过边界进入应用
若外观的pay方法仍返回Stripe专属的Payment Intent对象，则第三方耦合依然存在
改进做法是定义一个Payments协议，其pay方法返回与Stripe无关的自定义PaymentResult对象，使业务逻辑只依赖协议而不知具体实现
任何系统的对象在代码库中扩散时，都会让该系统塑造你的架构并引入大量耦合，适用于天气API、图形引擎、ORM、AI API等场景
外观实现得当时测试更容易，因为可以用mock对象（如FakeStripe实现相同接口）整体替换外观
实现外观时应避免纯粹的透传包装器，方法应暴露有业务意义的操作（如pay、refund_order）而非Stripe化的方法
实现外观时应避免造上帝外观（God Facade），应拆分成若干内聚独立的服务或类
还有 2 条时间轴事件
全部知识事实 (12)
外观模式（Facade Pattern）是四人帮（Gang of Four）在1994年《设计模式》一书中归纳的23种经典设计模式之一，属于结构型模式
50%待验证外观模式的核心思路是在复杂系统之上建立一个简化的接口，让业务逻辑不必直接面对底层复杂性
50%待验证外观并不阻止调用方绕过它直接访问子系统，它提供的是便利而非强制封装
50%待验证外观模式不只是简化调用，更重要的是作为一道边界，决定哪些信息可以越过边界进入应用
50%待验证若外观的pay方法仍返回Stripe专属的Payment Intent对象，则第三方耦合依然存在
50%待验证改进做法是定义一个Payments协议，其pay方法返回与Stripe无关的自定义PaymentResult对象，使业务逻辑只依赖协议而不知具体实现
50%待验证任何系统的对象在代码库中扩散时，都会让该系统塑造你的架构并引入大量耦合，适用于天气API、图形引擎、ORM、AI API等场景
50%待验证外观实现得当时测试更容易，因为可以用mock对象（如FakeStripe实现相同接口）整体替换外观
50%待验证实现外观时应避免纯粹的透传包装器，方法应暴露有业务意义的操作（如pay、refund_order）而非Stripe化的方法
50%待验证实现外观时应避免造上帝外观（God Facade），应拆分成若干内聚独立的服务或类
50%待验证实现外观时不应隐藏调用方真正需要知道的重要行为，如支付是否同步、客户认证是否必需
50%待验证适配器（Adapter）的目标是让接口兼容，而外观（Facade）的目标是简化对复杂子系统的访问
50%