外观模式

外观模式简单实现

UML类图：

（以下为摘抄部分）

 模式优点

       外观模式的主要优点如下：

       (1) 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。

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

       (3) 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。

 

 模式缺点

       外观模式的主要缺点如下：

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

       (2) 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则（可以加入抽象外观类）。

 

 适用场景

       在以下情况下可以考虑使用外观模式：

       (1) 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。

       (2) 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。

       (3) 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

#pragma once
#ifndef _FACADE_H
#define _FACADE_H
#include<string>
class SubSystem1
{
public:
	SubSystem1()
	{}
	~SubSystem1()
	{}
	void Operation()
	{
		puts("SubSystem1  Operation");
	}
};

class SubSystem2
{
public:
	SubSystem2()
	{}
	~SubSystem2()
	{}
	void Operation()
	{
		puts("SubSystem2  Operation");
	}
};

class Facade
{
public:
	Facade()
	{
		m_Sub1 = new SubSystem1();
		m_Sub2 = new SubSystem2();
	}
	~Facade()
	{
		delete m_Sub1;
		m_Sub1 = nullptr;
		delete m_Sub2;
		m_Sub2 = nullptr;
	}
	void Operation()
	{
		if (nullptr != m_Sub1)
		{
			m_Sub1->Operation();
		}
		if (nullptr != m_Sub2)
		{
			m_Sub2->Operation();
		}
	}
private:
	SubSystem1* m_Sub1;
	SubSystem2* m_Sub2;
};

//简单的Facade 模式 只用到类组合 不宜扩展
/*
当我们需要增加新的外观类 时不得不修改 Facade的代码 
因此我们加入抽象外观类，增加新外观类时 从抽象继承，
在配置文件中将类名替换，不但客户端感受不到任何变化，
任何代码也不用修改。
*/
#endif

#include<iostream>
#include"Facade.h"
using namespace std;
int main(void)
{
	SubSystem1* pSub1 = new SubSystem1();
	pSub1->Operation();
	SubSystem2* pSub2 = new SubSystem2();
	pSub2->Operation();
	delete pSub1;
	pSub1 = nullptr;
	delete pSub2;
	pSub2 = nullptr;
	//改用外观模式
	puts("---------------------");
	Facade* pFa = new Facade();
	pFa->Operation();
	delete pFa;
	pFa = nullptr;

	return 0;
}