本文共 1051 字，大约阅读时间需要 3 分钟。

目录

---

1.意图

  为了给子系统中一系列的接口提供一个统一的接口，外观模式定义了一个更高层次的接口，使得子系统更容易使用。

  外观模式不同于适配器模式，因为外观模式简化了类结构，而适配器模式维持类结构不变。   外观模式提供了一条在子系统中构造我们自己的API的途径，来减少子系统中API的大小以及复杂度的增长。

2.UML类图

  

3.GOF角色说明

Facade

--知道哪些子系统类负责处理请求。 --将客户的请求代理给适当的子系统对象。

Subsystem classes

--实现子系统的功能。 --处理由Facade对象指派的任务。 --没有facade的任何相关信息；即没有指向facade的指针。

4.代码实现

#include
   
    using namespace std;class SubSystem1{public:	void method1() 	{ cout<<"SubSystem1"<
    
     methodA();	fd->methodB();	delete fd;	return 0;}
    
   

运行结果为：

  Facade: methodA()   SubSystem1   SubSystem2   Facade: methodB()   SubSystem2   SubSystem3

5.实际场景

facade模式比较容易理解。也是日常开发中，经常使用到的一种模式。其实就是屏蔽了内部的各个子系统的复杂细节，调用者/外部方 只看到了系统提供的一个高层的，统一的接口。使得客户端非常容易接入系统。

比如：现在政府大力对政务办理流程进行简化。很多地方推出了让老百姓只跑一次腿的政策。就是在统一的政务大厅里，基本一次就可以办理好业务。不需要像以前一样，需要办事人自己跑税务，财政，车管所，派出所等等地方。而只需要在政务大厅的对外窗口，一次性办理好。而这个窗口，就相当于是政府的facade接口。

6.总结

a)外观模式不是万金油，并不适用于所有的场景。当子系统本来就比较简单，或者子系统数量很少时，就没必要使用外观模式了，否则就是多此一举，反倒增加复杂性和调用层次。

b)当子系统之间毫无关联，且上层难以利用子系统进行通用的抽象化组合时，也就无需使用外观模式。因为它的通用性太窄了，抽象的高层接口，与直接使用子系统接口，并无差异。 c)Abstract Factory(抽象工厂模式)，与facade有点类似。都可以用来隐藏子系统的内部具体实现。但facade一般更具有通用性。