外观模式Facade--结构型模式之四

1. 意图

为子系统中的一组接口提供一个一致的界面, F a c a d e模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

2. 动机

将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使

子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一是就是引入一个 外观

(facade)对象,它为子系统中较一般的设施提供了一个单一而简单的界面。



例如有一个编程环境,它允许应用程序访问它的编译子系统。这个编译子系统包含了若干个类,如 S c a n n e r、P a r s e r、P r o g r a m N o d e、B y t e c o d e S t r e a m和P r o g r a m N o d e B u i l d e r,用于实现这一编译器。有些特殊应用程序需要直接访问这些类,但是大多数编译器的用户并不关心语法分析和代码生成这样的细节;他们只是希望编译一些代码。对这些用户,编译子系统中那些功能强大但层次较低的接口只会使他们的任务复杂化。

为了提供一个高层的接口并且对客户屏蔽这些类,编译子系统还包括一个C o m p l i e r类。这个类定义了一个编译器功能的统一接口。 C o m p i l e r类是一个外观,它给用户提供了一个单一而简单的编译子系统接口。它无需完全隐藏实现编译功能的那些类,即可将它们结合在一起。编译器的外观可方便大多数程序员使用,同时对少数懂得如何使用底层功能的人,它并不隐藏这些功能,如下图所示。



3. 适用性

在遇到以下情况使用 Facade模式

• 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越

复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性,也更容

易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一些使用上的困难。

F a c a d e可以提供一个简单的缺省视图,这一视图对大多数用户来说已经足够,而那些需

要更多的可定制性的用户可以越过 facade层。

• 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入 f a c a d e将这个子系统与客

户以及其他的子系统分离,可以提高子系统的独立性和可移植性。

• 当你需要构建一个层次结构的子系统时,使用 f a c a d e模式定义子系统中每层的入口点。

如果子系统之间是相互依赖的,你可以让它们仅通过 f a c a d e进行通讯,从而简化了它们

之间的依赖关系。

4. 结构



5. 参与者

• Facade (Compiler)

— 知道哪些子系统类负责处理请求。

— 将客户的请求代理给适当的子系统对象。

• Subsystem classes (Scanner、Parser、ProgramNode等)

— 实现子系统的功能。

— 处理由Facade对象指派的任务。

— 没有facade的任何相关信息;即没有指向 facade的指针。

6. 协作

• 客户程序通过发送请求给 F a c a d e的方式与子系统通讯, F a c a d e将这些消息转发给适当的

子系统对象。尽管是子系统中的有关对象在做实际工作,但 F a c a d e模式本身也必须将它

的接口转换成子系统的接口。

• 使用Facade的客户程序不需要直接访问子系统对象。

7. 效果

Facade模式有下面一些优点:

1) 它对客户屏蔽子系统组件,因而减少了客户处理的对象的数目并使得子系统使用起来

更加方便。

2) 它实现了子系统与客户之间的松耦合关系,而子系统内部的功能组件往往是紧耦合的。

松耦合关系使得子系统的组件变化不会影响到它的客户。 F a c a d e模式有助于建立层次结构系

统,也有助于对对象之间的依赖关系分层。 F a c a d e模式可以消除复杂的循环依赖关系。这一

点在客户程序与子系统是分别实现的时候尤为重要。

转自《设计模式》