Facade 模式

Facade外 观模式，是一种结构型模式，它主要解决的问题是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合 面临很多变化的挑战。在这里我想举一个例子：比如，现在有一辆汽车，我们（客户程序）要启动它，那我们就要发动引擎（子系统1），使四个车轮（子系统2）转动。但是实际中我们并不需要用手推动车轮使其转动，我们踩下油门，此时汽车再根据一些其他的操作使车轮转动。油门就好比系统给我们留下的接口，不论汽车是以何种方式转动车轮，车轮变化成什么牌子的，我们要开走汽车所要做的还是踩下油门。

GoF《设计模式》中说道：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

Façade外观模式的结构大概是这样的：

 

Façade模式的几个要点：

    1、从客户程序的角度看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。

2、Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。

Facade 模式还可以用来隐藏或封装原来的系统。 Facade 类可以把原来的系统当成私有变量。这样，原始系统就仅仅和 Facade 类有联系而不会暴露给 Facade 类的使用者。

正如下面将要提到的，我们有很多理由来封装系统：

    追踪系统使用 －通过限制所有对系统功能的调用必须由 Facade 类来完成，我们可以非常方便地监视系统使用状况。

    在系统间进行切换 －有可能在将来我们所使用的系统会有所改变。通过把原始系统当成 Facade 类的私有成员变量 (private member) 来处理，我们可以很轻易的切换我们所使用的系统。当然，也许仍然有巨大的工作量，但是至少，我只需要改变一个地方 (Facade 类 ) 。

总结

外观模式 (Facade Pattern) 名称的得来是因为她在原始系统的前面建立了一个新的接口 (Facade 类 ) 。

我们将在以下的情况中使用到 Facade 模式：

l、当不需要使用一个复杂系统的所有功能时。创建一个类来包含所有使用这个系统的规则、方法。

   通常，我们会用到一个原始系统的子系统，新创建的类的接口 (API) 将会比原始系统的接口 (API) 简单得多。

2、 当想要封装或隐藏原始系统时。

3、当想要使用原始系统的某些功能并添加新功能时。

   4 、当编写新类的花费要低于项目组每个人都学习如何使用原始系统或者低于在后期维护时的投入的时候。