前言
在实际开发时，面对一个大的系统，总是会将一个大的系统分成若干个子系统，等子系统完成之后，再分别调用对应的子系统来完成对应的整体功能，这样有利于降低系统的复杂性；最终进行实现某个具体的功能时，我们将对应的子系统进行组合就好了；但是，子系统那么多，关系那么复杂，组合形成一个完整的系统，是存在难度的。
我们在使用visual studio进行编译c 代码时，你只是在菜单中选择了build，然后visual studio就开始了一堆的编译工作；你应该知道，因为你的一个简单的build动作，编译器在后台会进行语法分析，生成中间代码，生成汇编代码，链接成可执行程序或库等等动作；而这一切，作为只是开发程序的我们，而不用去理解编译器在做什么的，编译器向我们隐藏了背后的一系列复杂操作，而只提供一个build按钮，这个build按钮，就可以执行一切的操作；当单击这个build按钮时，build在幕后，将任务分发给不同的子系统去完成，最终子系统进行协作完成了整个的编译任务。而这样隐藏一些复杂操作，只提供一个更高层的统一接口，就是我今天总结的外观模式。
什么是外观模式？
外观模式，很多人也把它叫做门面模式。在gof的《设计模式:可复用面向对象软件的基础》一书中对外观模式是这样说的：将子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。细细的理解这句话；子系统中的一组接口，就好比上面举得例子中的语法分析，生成中间代码，生成汇编代码，链接成可执行程序或库；外观模式定义的一个高层接口，就好比上面说的build按钮，通过这样的一个build按钮，让编译器更加容易使用，对于这一点，从linux c /c转windows c /c的程序员是最有体会的。visual studio提供的强大功能，只需要一个build按钮，就可以进行build动作，而不需要去写makefile文件，然后再去执行一些命令进行编译。
uml类图
facade:知道哪些子系统类负责处理请求，并且将客户的请求代理给适当的子系统对象；
subsystem:实现子系统具体的功能；处理由facade对象指派的任务；但是，subsystem没有facade的任何相关信息，也就是说，没有指向facade的指针。
client通过发送请求给facade的方式与子系统进行通信，而不直接与子系统打交道，facade将这些消息转发给适当的子系统对象。尽管是子系统中的有关对象在做实际工作，但facade模式本身也必须将它的接口转换成子系统的接口，这里是不是有点适配器模式的感觉呢？这就是学习结构型设计模式的感觉，感觉都很相似，但是仔细的去研究时，就会发现各自的用处。
代码实现
这里实现的代码就是参照我上面举的编译器的例子。
/*
** filename : facadepatterndemo
** description : more information, please go to https://www.coonote.com
*/
#include
using namespace std;
// 语法分析子系统
class csyntaxparser
{
public:
void syntaxparser()
{
cout<<"syntax parser"<
上面的代码很简单。我们可以想象，如果没有使用外观模式，在客户端如果要进行compile同样的动作时，就需要写一堆和compile中一样的代码；是的，你会说，写就写吧。但是，有的时候，客户端并不会非常熟悉子系统之间的关系，就好比，先要进行语法分析，再生成中间代码，然后生成汇编语言，最后进行链接一样。如果客户端不知道这个时序，那怎么办？所以，外观模式让一切复杂的东西，使用起来都变的简单了。
优点
- 它对客户屏蔽了子系统组件，因而减少了客户处理的对象的数目，并使得子系统使用起来更加方便；
- 它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的；松耦合系统使得子系统的组件变化不会影响到它的客户。外观模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。外观模式可以消除复杂的循环依赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要。
使用场合
- 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变的越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具有可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。外观模式可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过facade层；
- 当客户程序与抽象类的实现部分之间存在很大的依赖性。引入facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性；
- 当需要构建一个层次结构的子系统时，使用外观模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，我们就可以让它们仅通过facade进行通讯，从而简化了它们之间的依赖关系。
总结
外观模式简单易用，让客户能更简单的去使用子系统；在拜读别人的文章时，有以下总结非常好，我也借鉴一下：
- 在设计初期，应该有意识的将不同层分离，比如常用的三层架构，就是考虑在数据访问层，与业务逻辑层表示层之间，建立facade，使复杂的子系统提供一个简单的接口，降低耦合性；
- 在开发阶段，子系统往往因为不断的重构而变的越来越复杂，增加外观facade可以提供一个简单的接口，减少它们之间的依赖；
- 在维护阶段，可能这个系统已经非常难以维护和扩展了，此时你可以为新系统开发一个外观类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与facade对象交互，facade与遗留代码交互所有复杂的工作。
通常来讲，对于子系统的访问，我们提供一个facade层，而这个facade入口，只需要一个；也就是说在使用facade时，我们可以使用单例模式来实现facade模式。