动机
下图中左边方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。
如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？
将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一是就是引入一个 外观（facade）对象，它为子系统中较一般的设施提供了一个单一而简单的界面。
例如有一个编程环境，它允许应用程序访问它的编译子系统。这个编译子系统包含了若干个类，如 Scanner、Parser、ProgramNode、BytecodeStream 和 ProgramNodeBuilder，用于实现这一编译器。有些特殊应用程序需要直接访问这些类，但是大多数编译器的用户并不关心语法分析和代码生成这样的细节；他们只是希望编译一些代码。对这些用户，编译子系统中那些功能强大但层次较低的接口只会使他们的任务复杂化。
为了提供一个高层的接口并且对客户屏蔽这些类，编译子系统还包括一个 Compiler 类。这个类定义了一个编译器功能的统一接口。 Compiler 类是一个外观，它给用户提供了一个单一而简单的编译子系统接口。它无需完全隐藏实现编译功能的那些类，即可将它们结合在一起。编译器的外观可方便大多数程序员使用，同时对少数懂得如何使用底层功能的人，它并不隐藏这些功能，如下图所示。
Facade模式定义
为子系统中的一组接口提供一个一致的界面， Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Facade结构
参与者
• Facade (Compiler)
--- 知道哪些子系统类负责处理请求。
--- 将客户的请求代理给适当的子系统对象。
• Subsystem classes (Scanner、Parser、ProgramNode 等)
--- 实现子系统的功能。
--- 处理由 Facade 对象指派的任务。
--- 没有 facade 的任何相关信息；即没有指向 facade 的指针。
协作
• 客户程序通过发送请求给 Facade 的方式与子系统通讯， Facade 将这些消息转发给适当的子系统对象。尽管是子系统中的有关对象在做实际工作，但 Facade 模式本身也必须将它的接口转换成子系统的接口。
• 使用 Facade 的客户程序不需要直接访问子系统对象。
要点总结
从客户程序的角度来看，Façade模式简化了整个组件系统的接口， 对于组件内部与外部客户程序来说，达到了一种"解耦"的效 果------内部子系统的任何变化不会影响到Façade接口的变化。
Façade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Façade很多时候更是一种架构设计模式。
Façade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是"相互耦合关系比较大的一系列 组件"，而不是一个简单的功能集合。