外观模式为子系统中的一组接口提供了一个一致的界面,此模式定义了一个高层接口,这个接口使得这一个子系统更加容易使用
上代码:
#include <iostream>
#include <string>
using namespace std;
class SubSystemOne
{
public:
void MethodOne()
{
cout << "子系统方法一" << endl;
}
};
class SubSystemTwo
{
public:
void MethodTwo()
{
cout << "子系统方法二" << endl;
}
};
class SubSystemThree
{
public:
void MethodThree()
{
cout << "子系统方法三" << endl;
}
};
class SubSystemFour
{
public:
void MethodFour()
{
cout << "子系统方法四" << endl;
}
};
class Facade
{
public:
Facade()
{
one = new SubSystemOne;
two = new SubSystemTwo;
three = new SubSystemThree;
four = new SubSystemFour;
}
~Facade()
{
cout << "delete here" << endl;
delete one;
delete two;
delete three;
delete four;
}
void MethodA()
{
cout << "方法组A:" << endl;
one->MethodOne();
two->MethodTwo();
three->MethodThree();
}
void MethodB()
{
cout << "方法组B:" << endl;
two->MethodTwo();
three->MethodThree();
four->MethodFour();
}
private:
SubSystemOne *one;
SubSystemTwo *two;
SubSystemThree *three;
SubSystemFour *four;
};
int main()
{
Facade *test = new Facade;
test->MethodA();
test->MethodB();
delete test;
}
从代码中可以看出,客户端只是知道外观类(Facade)有什么方法,但不需知道Facade的方法是怎么实现的,根据迪米特法则,如果两个类不必彼此发生通信,那么这两个类之间就不应该发生直接的相互作用,就像上面的代码,客户端实现了自己想要的功能(MethodA),而且客户端在不知情的情况下调用了子系统的方法MethodOne,这个调用是通过第三方(Facade)来实现的,这样的话当要增加子系统类的时候就不会影响到调用那些调用这些系统的用户程序,因为约定好了一个接口(看成是Facade),这也是依赖倒转法则的体现。
在设计初期的时候,就应该将不同的两个层分离,例如在业务逻辑层和表示层之间建立外观类Facade,就像上面那样,这样的话可以为复杂的子系统提供一个简单的接口,实现了松耦合,还有就是在开发阶段的时候,子系统的功能往往会有所增加或者修改,有了接口的话就减少了修改的麻烦