外观模式Facade

外观模式，实际上是我在开源软件ZStack中发现在其中进行了运用的。那什么是外观模式呢？
外观模式，实际上有点像肯德基的点餐窗口。我们在需要吃饭的时，只需要在窗口给店员说：我需要饮料和面包，而不用关心后厨如何去从饮料机接饮料、从面包机拿面包等等。“前台”就是我们所定义的外观模式。
因此外观模式的优点显而易见，那就是可以屏蔽调后面复杂的子系统，只需要使用统一的接口就好。当后台系统发生更换的时候，前台也不用更换。这样就可以降低使用的复杂度，能够更好地维护程序。
ZStack在系统中大量运用了外观模式。如RESTFul的访问，异步post访问，timer设置等等，都是用外观模式进行的包装组合。

外观模式

上图来自引用“http://blog.csdn.net/hguisu/article/details/7533759”

这副图是一片博客中的图，画的非常清晰明了。在多个子系统之上，定义了一个外观类，用于统一访问子系统，提供统一的接口。client只需要于外观类交互就行了。
具体来讲，外观模式包含如下三个部分：

结构组成

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

使用场景

1.当子系统比较多时，可以对某些客户提供已经打包组装好的服务，就可以用外观类统一打包。对于少数需要个性化组合的客户，可以单独再组合。
2.在构建层次结构时，外观类可以作为每个层次的入口
3.可以促进系统的解耦。

缺点

看上去外观模式很好，但是也是有问题的。
1.对于子系统的控制不是很灵活。控制太多也较少可变性。控制太少，那他本身的意义也不是很大。
2.如果在需要新增加子系统时，可能需要修改外观类源玛，违反“开闭原则”