设计模式之外观模式

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

UML图如下：

2、如何使用外观模式？

这要分三个阶段来说，首先，在设计初期阶段，应该要有意识的将不同的两个层分离，比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层，业务逻辑层和表示层的层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。

其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，大多数的模式使用时也都会产生很多的小类，这本书好事，但是也给外部调用它们的用户程序带来使用上的困难，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。

第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展，但因为它包含非常重要的功能新的需求开发必须要依赖它。此时用外观模式也是非常合适的。你可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。 

协作

----客户程序通过发送请求给Facade的方式与子系统通讯，Facade将这些消息转发给适当的子系统对象。尽管是子系统中的有关对象在做实际工作，但Facade模式本身也必须将它的接口转换成子系统的接口。

----使用Facade的客户程序不需要直接访问子系统对象。

 C++ Code 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70

#include <iostream> using  namespace std; class SystemOne { public:      void MethodOne()     {         cout <<  "子系统方法一" << endl;     } }; class SystemTwo { public:      void MethodTwo()     {         cout <<  "子系统方法二" << endl;     } }; class SystemThree { public:      void MethodThree()     {         cout <<  "子系统方法三" << endl;     } }; class SystemFour { public:      void MethodFour()     {         cout <<  "子系统方法四" << endl;     } }; //外观类 class Facade { private:     SystemOne one;     SystemTwo two;     SystemThree three;     SystemFour four; public:      void MethodA()     {         cout <<  "方法组A" << endl;         one.MethodOne();         two.MethodTwo();         four.MethodFour();     }      void MethodB()     {         cout <<  "方法组B" << endl;         two.MethodTwo();         three.MethodThree();     } }; int main() {     Facade face;     face.MethodA();     face.MethodB();      return  0; }

    外观模式应该是用的很多的一种模式，特别是当一个系统很复杂时，系统提供给客户的是一个简单的对外接口，而把里面复杂的结构都封装了起来。客户只需使用这些简单接口就能使用这个系统，而不需要关注内部复杂的结构。

     DP一书的定义：为子系统中的一组接口提供一个一致的界面， 外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。举个编译器的例子，假设编译一个程序需要经过四个步骤：词法分析、语法分析、中间代码生成、机器码生成。学过编译都知道，每一步都很复杂。对于编译器这个系统，就可以使用外观模式。

可以定义一个高层接口，比如名为Compiler的类，里面有一个名为Run的函数。客户只需调用这个函数就可以编译程序，至于Run函数内部的具体操作，客户无需知道。

下面给出UML图，以编译器为实例。

相应的代码实现为：

[cpp]  view plain copy

1. class Scanner  
2. {  
3. public:  
4.     void Scan() { cout<<"词法分析"<<endl; }  
5. };  
6. class Parser  
7. {  
8. public:  
9.     void Parse() { cout<<"语法分析"<<endl; }  
10. };  
11. class GenMidCode  
12. {  
13. public:  
14.     void GenCode() { cout<<"产生中间代码"<<endl; }  
15. };  
16. class GenMachineCode  
17. {  
18. public:  
19.     void GenCode() { cout<<"产生机器码"<<endl;}  
20. };  
21. //高层接口  
22. class Compiler  
23. {  
24. public:  
25.     void Run()   
26.     {  
27.         Scanner scanner;  
28.         Parser parser;  
29.         GenMidCode genMidCode;  
30.         GenMachineCode genMacCode;  
31.         scanner.Scan();  
32.         parser.Parse();  
33.         genMidCode.GenCode();  
34.         genMacCode.GenCode();  
35.     }  
36. };  

       客户使用方式：

[cpp]  view plain copy

1. int main()  
2. {  
3.     Compiler compiler;  
4.     compiler.Run();  
5.     return 0;  
6. }  

        这就是外观模式，它有几个特点（摘自DP一书），（1）它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。（2）它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。（3）如果应用需要，它并不限制它们使用子系统类。

       结合上面编译器这个例子，进一步说明。对于（1），编译器类对客户屏蔽了子系统组件，客户只需处理编译器的对象就可以方便的使用子系统。对于（2），子系统的变化，不会影响到客户的使用，体现了子系统与客户的松耦合关系。对于（3），如果客户希望使用词法分析器，只需定义词法分析的类对象即可，并不受到限制。