设计模式之外观模式

外观模式，Facade，翻译为，外观，正面，虚伪，假象的意思。

也就是说外观模式，只是一种简单对以前的类，或者子系统进行封装，一致对外提供统一接口的，并没有在原来的基础上增加任何的行为。

如果，在没有设计外观模式之前，子系统之间相互依赖，客户端调用的时候，就会相互交错，耦合性高，有了外观系统，可以把他们解耦。

外观角色（Facade）：是模式的核心，他被客户client角色调用，知道各个子系统的功能。同时根据客户角色已有的需求预订了几种功能组合\
子系统角色（Subsystem classes）：实现子系统的功能，并处理由Facade对象指派的任务。对子系统而言，facade和client角色是未知的，没有Facade的任何相关信息；即没有指向Facade的实例。
客户角色（client）：调用facade角色获得完成相应的功能。

Facade一个典型应用就是进行数据库连接。一般我们在每一次对数据库进行访问，都要进行以下操作：先得到connect实例，然后打开connect获得连接，得到一个statement，执行sql语句进行查询，得到查询结果集。

       我们可以将这些步骤提取出来，封装在一个类里面。这样，每次执行数据库访问只需要将必要的参数传递到这个类中就可以了。

外观模式一般在系统架构设计的时候会用到。

外观模式，其实，就是一个中间类，把子类，加装在一起。

所以它有一个缺点就是不符合，开闭原则，假如有一天，又产生了一个新类，那么这个外观模式类，必须重新再写。

门面模式从整体来看，给我的感觉是，它对于使两层之间的调用粗颗粒化很有帮助，避免了大量细颗粒度的访问。这和SOA中的一些观点是相同的。

可以推荐看看这个简单的例子：

http://zz563143188.iteye.com/blog/1847029