设计模式(10) - Facade外观模式

目录

1.意图

2.UML类图

3.GOF角色说明

4.代码实现

5.实际场景

6.总结

---

1.意图

  为了给子系统中一系列的接口提供一个统一的接口，外观模式定义了一个更高层次的接口，使得子系统更容易使用。
  外观模式不同于适配器模式，因为外观模式简化了类结构，而适配器模式维持类结构不变。
  外观模式提供了一条在子系统中构造我们自己的API的途径，来减少子系统中API的大小以及复杂度的增长。

2.UML类图

  

3.GOF角色说明

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

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

4.代码实现

#include<iostream>

using namespace std;

class SubSystem1
{
public:
	void method1() 
	{ cout<<"SubSystem1"<<endl; }
};

class SubSystem2
{
public:
	void method2() 
	{ cout<<"SubSystem2"<<endl; }
};

class SubSystem3 
{
public:
	void method3()
	{ cout<<"SubSystem3"<<endl;}
};

//Facade
class Facade
{
public:
	void methodA()	{
		cout<<"Facade: methodA()"<<endl;
		sub1.method1();
		sub2.method2();
	}

	void methodB()	{
		cout<<"Facade: methodB()"<<endl;
		sub2.method2();
		sub3.method3();
	}
private:
	SubSystem1 sub1;
	SubSystem2 sub2;
	SubSystem3 sub3;
};

int main()
{
	Facade *fd = new Facade();
	fd->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一般更具有通用性。