一、引子
门面模式是非常简单的设计模式。
二、定义与结构
门面模式（facade）又称外观模式。GOF在《设计模式》一书中给出如下定义：为子系
统中的一组接口提供一个一致的界面， Facade模式定义了一个高层接口，这个接口使得这
一子系统更加容易使用。
定义中提到的子系统是指在设计中为了降低复杂性根据一定的规则（比如业务、功能），
对系统进行的划分。子系统中封装有一些类。客户程序在使用子系统的时候，可能会像下图
一样零乱。
在上面的实现方法中，客户类紧紧地依赖在子系统的实现上。子系统发生的变化，很可
能要影响到客户类的调用。而且子系统在不断优化、可重用化的重构路上，会产生更多更小
的类。这对使用子系统的客户类来说要完成一个工作流程，似乎要记住的接口太多了。
门面模式就是为了解决这种问题而产生的。看看使用了门面模式后的图：
这样就减少了客户程序和子系统之间的耦合，增加了可维护性。
很明显，门面模式有三个角色组成：
1) 门面角色（facade）：这是门面模式的核心。它被客户角色调用，因此它熟悉子系统的
功能。它内部根据客户角色已有的需求预定了几种功能组合。
2) 子系统角色：实现了子系统的功能。对它而言，facade角色就和客户角色一样是未知的，
它没有任何facade角色的信息和链接。
3) 客户角色：调用facade角色来完成要得到的功能。
三、举例
Facade 模式的一个典型应用就是进行数据库连接。一般我们在每一次对数据库进行访
问，都要进行以下操作：先得到connect 实例，然后打开connect 获得连接，得到一个
statement，执行sql 语句进行查询，得到查询结果集。
我们可以将这些步骤提取出来，封装在一个类里面。这样，每次执行数据库访问只需要
将必要的参数传递到这个类中就可以了。
有兴趣可以在你正在进行的系统中实现一下。
四、使用环境和优点
《设计模式》给出了门面模式的使用环境：
1) 当你要为一个复杂子系统提供一个简单接口时。在上面已经描述了原因。
2) 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入facade 将这个子系统与
客户以及其他的子系统分离，可以提高子系统的独立性和可移植性（上面也提到了）。
3) 当你需要构建一个层次结构的子系统时，使用facade 模式定义子系统中每层的入口点。
如果子系统之间是相互依赖的，你可以让它们仅通过facade 进行通讯，从而简化了它
们之间的依赖关系。
以下是它的优点：
1) 它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更
加方便。
2) 它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。
松耦合关系使得子系统的组件变化不会影响到它的客户。Facade 模式有助于建立层次
结构系统，也有助于对对象之间的依赖关系分层。Facade 模式可以消除复杂的循环依
赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要。在大型软件系统中降
低编译依赖性至关重要。在子系统类改变时，希望尽量减少重编译工作以节省时间。用
Facade 可以降低编译依赖性，限制重要系统中较小的变化所需的重编译工作。Facade
模式同样也有利于简化系统在不同平台之间的移植过程，因为编译一个子系统一般不需
要编译所有其他的子系统。
3) 如果应用需要，它并不限制它们使用子系统类。因此你可以让客户程序在系统易用性和
通用性之间加以选择。
五、总结
从整体上来看门面模式给我的感觉是，它对于使两层之间的调用粗颗粒化很有帮助，避
免了大量细颗粒度的访问。这和SOA 中的一些观点是相同的。
下载：
http://download.csdn.net/detail/undoner/5335717
问题：
1,外观模式的应用范围及缺点？
答：<1>应用范围:对于复杂的子系统，需给用户提供一个简单的操作；不希望客户代码与子系统代码耦合，便于提高子系统独立性和可移植性。<2>局限性:它不能很好限制客户类直接访问子系统角色，这样子又违反了"开闭原则"。
2,外观模式如何改进以更好的遵守“开闭原则”？
答：引入抽象外观类进而扩展外观模式，客户只用与抽象外观类交互，再由具体外观类实现相应不同的操作即可。
3,外观模式各个角色承担的具体作用？
答：有外观角色、子系统角色、客户角色三个。由客户与外观角色直接交互，再由外观角色统一部署控制子系统各个角色，实现分层。