【设计模式学习笔记十一】【结构型模式】【外观模式(Facade)】

本文是学习刘伟技术博客和《设计模式-可复用面向对象软件的基础》笔记，博客链接：http://blog.csdn.net/lovelion/article/details/17517213

主要是对博客和书本做提炼和记录，更多是对设计模式的基础框架学习，细节将略去，侧重对每个设计模式框架的理解。

我应该理解和掌握的：

1）能够画出这个设计模式的架构框图；

2）能够根据架构框图写出对应的伪代码；

3）这个模式的应用场景，主要优缺点。

1.外观模式（Facade）

外观模式通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的接口，降低子系统与客户端的耦合度，且客户端调用非常方便。最简单的例子就是班长这个角色，对于客户端（班主任来说），他直接分配任务给班长，班长在分配给各个委员，比如学习委员，体育委员等待。将委员看做一个个子系统，那么班长的角色就相当于外观类角色。班主任只需要和班长交互即可。

（1）定义

外观模式：为系统中的一组接口提供一个一致的界面，Facade模式提供定义了一个高层次接口，这个接口使得这一子系统更加容易使用。

它又称门面模式，通过引入一个新的外观角色可以降低原有系统的负责度，同时降低客户类与子系统的耦合度。外观类将客户类与子系统的内部复杂性分隔开，使得客户类只需要和外观角色打交道，而不需要与子系统内部的很多对象打交道。

1）外观模式结构图

2）参与者

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

b) SubSystem：存在一个或多个子系统（子系统可以是单独类或是类集合）；实现子系统功能，处理由Facade对象指派的任务；没有Facade的任何相关信息，即没有指向Facade的指针。

c) 客户通过发送请求给Facade的方式与子系统通讯，通过Facade转发给子系统，客户不需直接访问子系统。

3）看图写代码

/*
** FileName     : FacadePattern
** Author       : lin005
** Date         : 2015/01/28
** Description  : More information, please go to http://blog.csdn.net/amd123456789
*/
//子系统A
class SubSystemA
{
public:
	void method()
	{
		cout<<"SubSystemA method"<<endl;
	}
};
//子系统B
class SubSystemB
{
public:
	void read()
	{
		cout<<"SubsystemB read()"<<endl;
	}
};
//子系统C
class SubSystemC
{
public:
	void write()
	{
		cout<<"System write()"<<endl;
	}
};
//外观类角色
class Facade
{
public:
	Facade()
	{
		sa = new SubSystemA();
		sb = new SubSystemB();
		sc = new SubSystemC();
	}
	~Facade()
	{
	
		if(sa != NULL)
		{
			delete sa;
			sa = NULL;
		}
		if(sb != NULL)
		{
			delete sb;
			sb = NULL;
		}
		if(sc != NULL)
		{
			delete sc;
			sc = NULL;
		}
	}
	//提供给客户端的接口
	void compile()
	{
		//调用各个子系统的接口，统一在这里进行修改
		sa->method();
		sb->read();
		sc->write();
	}
private:
	//关联各个子系统
	SubSystemA* sa;
	SubSystemB* sb;
	SubSystemC* sc;
};
//客户端测试
int main()
{
	//客户端只需调用外观模式的接口，不需知道具体的子系统接口
	Facade *fa = new Facade();
	fa->compile();
	if(fa != NULL)
	{
		delete fa;
		fa = NULL;
	}
	return 0;
}

（2）总结

1）优点

a) 它对客户屏蔽了子系统组件。减少了客户处理的对象的数目并使得子系统使用起来更加方便。

b) 实现了客户与子系统之间的松耦合关系。使得子系统变化不会影响到客户端，只需要调整外观类即可。

c) 有助于建立层次结构系统，也有助于对对象之间的依赖关系分层，可以消除复杂的循环依赖关系。

2）缺点

a) 不能很好的限制客户端直接使用子系统，如果对客户端访问子类做太多的限制则减少了可变性和灵活性。

b) 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背开闭原则。

3）注意事项

a) 用抽象类实现Facade，而他的具体子类对应与不同的子类系统实现，可以进一步降低客户和子系统的耦合度。客户通过抽象的Facade和子系统通讯，我们只需在客户端生成具体Facade类，替换Facade抽象类的子类便可。这种抽象耦合关系似的客户不需知道它使用的是子系统的哪一个实现。

（3）适用场景

1） 当你要为访问一系列复杂的子系统提供一个简单的接口时。

2）客户程序与多个子系统之间存在很大的依赖关系。引入Facade，将这个子系统与客户端解耦，提高系统的独立性和可移植性。

3）当你需要建立一个层次结构的子系统时，使用Facade定义子系统中每层的入口点。层与层之间不直接产生联系，而是通过外观类建立联系，降低层与层之间的耦合度。