门面模式
一、引子
是非常简单的设计模式。
二、定义与结构
（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 中的一些观点是相同的。
本书评论