C++设计模式（9）：外观模式

一、背景

一个系统由多个子系统组合而成，该整系统提供的某个功能是由各个子系统的子功能组合而成，客户端想要使用该功能，需要遵循一定的规则分别去调用对应子系统提供的子功能接口，这使得客户端陷入到复杂的子系统泥潭中，因为客户端需要了解子系统之间的依赖关系才能够使用该功能，使用极其不方便，且不能够复用。
在客户端和子系统间增加一层外观类，外观类面向客户端提供一个简单的功能接口，该接口负责调用子系统的子功能接口，子系统将外观类当成一种客户端，这样真正的客户端Client就可以与复杂的子系统解耦。使得客户端使用功能更加简单，且接口可以最大限度复用。

二、模式定义

外观模式是一种使用频率非常高的结构型设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，降低子系统与客户端的耦合度，且客户端调用非常方便。

有了外观模式，通过实现一个提供更加合理的接口外观类，你可以将一个复杂的子系统变得容易使用，如果你需要复杂的子系统的强大威力，别担心，还是可以使用原来的接口；但是你需要的是一个方便使用的接口，那就使用外观。

模式解读：

1. 外观类没有封装子系统的类，只是提供简化的接口，客户依然可以使用子系统复杂的类。
2. 外观模式将客户从复杂的子系统中解耦出来。
3. 外观模式的目的不是给予子系统添加新的功能接口，而是为了让外部减少与子系统内多个模块的交互，松散耦合，从而让外部能够更简单地使用子系统。

外观模式的本质是：封装交互，简化调用。

三、模式角色和UML类图

Facade（外观角色）：在客户端可以调用它的方法，在外观角色中可以知道相关的（一个或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。

SubSystem（子系统角色）：在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

UML类图分析
现在有一个系统，其中含有很多子系统，假如要实现一个A功能，需要调用子系统的各个接口func1-funx11。在没有外观类的情况下，客户端需要依次去调用子系统提供的接口，这样客户端的操作很复杂，加入外观类后，我们将子系统提供的这个A功能实现为一个功能接口func_A，该功能接口负责去调用func1-func11，这样客户端不需要再直接面向复杂的子系统，只需要与外观类的func_A打交道即可。

代码示例：

#include<iostream>
using namespace std;
/* 子系统A */
class SubSystem_A {
public:
	void operationA() {
		cout << "SubSystem_A's operationA excute." << endl;
	}
};
/* 子系统B */
class SubSystem_B{
public:
	void operationB() {
		cout << "SubSystem_B's operationB excute." << endl;
	}
};
/* 子系统C */
class SubSystem_C {
public:
	void operationC() {
		cout << "SubSystem_C's operationC excute." << endl;
	}
};
/* 外观类 */
class Facade {
public:
	Facade() {
		m_SubSystemA = new SubSystem_A();
		m_SubSystemB = new SubSystem_B();;
	    m_SubSystemC = new SubSystem_C();;
	}
	void wrapOpration() {
		m_SubSystemA->operationA();
		m_SubSystemB->operationB();
		m_SubSystemC->operationC();
	}
private:
	SubSystem_A *m_SubSystemA;
	SubSystem_B *m_SubSystemB;
	SubSystem_C *m_SubSystemC;
};
/* 客户端 */
int main() {
	Facade fa;
	fa.wrapOpration();
	return 0;
}

四、模式总结

使用场景

1. 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。
2. 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。
3. 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

优点

1. 对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。
2. 实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可。
3. 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
4. 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类

缺点

1. 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
2. 如果设计不当，增加或者删除新的子系统可能需要修改外观类的源代码，违背了开闭原则。