前言

在实际开发时，面对一个大的系统，总是会将一个大的系统分成若干个子系统，等子系统完成之后，再分别调用对应的子系统来完成对应的整体功能，这样有利于降低系统的复杂性；最终进行实现某个具体的功能时，我们将对应的子系统进行组合就好了；但是，子系统那么多，关系那么复杂，组合形成一个完整的系统，是存在难度的。

我们在使用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模式本身也必须将它的接口转换成子系统的接口，这里是不是有点适配器模式的感觉呢？这就是学习结构型设计模式的感觉，感觉都很相似，但是仔细的去研究时，就会发现各自的用处。

代码实现

这里实现的代码就是参照我上面举的编译器的例子。