程序设计模式(十) C++ 外观(Facade)模式

2.5 Facade

想想我们小时候玩的四驱车，里面的构造很复杂，马达，舵机，电池组等等，而我们控制它却非常简单，只要打开电池开关，他就可以跑。我们其实不用知道它里面是如何工作，只要知道拨动开关它就可以工作就行了，这个开关其实就四驱车给我们的一个友好的组件，使得我们可以很方便的控制它。外观模式其实定义了一个高层接口，该接口为子系统中的一组接口提供一个一致的界面，使得这一子系统更加容易使用。

思想：为子系统中的一组接口提供一个一致的界面，这个接口使得这一子系统更加容易使用。

1．Facade模式对客户屏蔽了子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。

2．Facade模式实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变

化不会影响到它的客户。

3．如果应用需要，它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。

4. 在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。当然这并不意味着在整个系统里

只能有一个外观类，而仅仅是说对每一个子系

统只有一个外观类。或者说，如果一个系统有好几个子系统的话，每一个子系统有一个外观类，整个系统可以有数个外观类。

5. 外观模式的用意是为子系统提供一个集中化和简化的沟通管道，而不建议向子系统加入新的行为。

6. 外观模式注重的是简化接口，它更多的时候是从架构的层次去看整个系统，而并非单个类的层次。

适用性：

1．为一个复杂子系统提供一个简单接口。

2．提高子系统的独立性。

3．在层次化结构中，可以使用Facade模式定义系统中每一层的入口。

优点:

1. 松散耦合
   

外观模式松散了客户端与子系统的耦合关系，让子系统内部的模块能更容易扩展和维护。

2.  简单易用

    外观模式让子系统更加易用，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟外观

交互就可以了，相当于外观类为外部客户端使用子系统提供了一站式服务。

3. 更好的划分访问层次
 

通过合理使用Facade，可以帮助我们更好的划分访问的层次。有些方法是对系统外的，有些方法是系统内部使用的。把需要暴露

给外部的功能集中到外观中，这样既方便客户端使用，也很好的隐藏了内部的细节。

缺点：      

过多的或者是不太合理的Facade也容易让人迷惑，到底是调用Facade好呢，还是直接调用模块好。

场景：将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统间的通信和相互

依赖关系达到最小。达到该目标的途径之一是就是引入一个外观（Facade）对象，它为子系统中较一般的设施提供了一个单一而简

单的界面。将各个子系统整合起来作为Facade，提供给客户端使用。当你要为一个复杂子系统提供一个简单接口时，子系统往往因为

不断演化而变得越来越复，大多数模式使用时都会产生更多更小的类，这使得子系统更具可重用性，也更容易对子系统进行定制，但

这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已

经足够，而那些需要更多的可定制性的用户可以越过Facade层。客户程序与抽象类的实现部分之间存在着很大的依赖性。引入

Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。当你需要构建一个层次结构的子系统

时，使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化

了它们之间的依赖关系。

实现：以文件系统为例，文件系统是一个独立的系统，它提供一套核心的文件操作。除了文件系统，还有四个子系统，分别是杀毒

子系统(KillVirus)，压缩子系统(ZipFile)，加密子系统(EncrypeFile)和刻录子系统(BurnCD)，这四个子系统相互独立，但又可以做为主

系统功能的一部分。假设客户需要我这个文件系统有两种执行模式，一种是完全模式，一种是简单模式。完全模式，要求杀毒子，压

缩，加密和刻录功能都有。简单模式，要求只要有杀毒，刻录就行了。

第一种设计：

文件系统自己管理所有的子系统，并实现客户的需求。

最开始的话，我们是按上面的结构来设计的，这个文件系统(FileSys)就要自己管理和组织上面的四个子系统。问题是子系统变化比较

多，特别是重构之后，接口也变了，这时也要相应的修改这个文件系统。最麻烦的是，有时一个子系统要分离出好多小类，这对子系

统是好事，但是对FileSys来说，调用越来越复杂和困难了。这种设计的问题是：文件系统和子系统耦合性太高了！

第二种设计：

后来我们独立出一个中间层，由中间层来统一管理这些子系统，并对外提供相对简单的接口，使它们之间减少依赖。

代码实现：

1. //杀毒  
2. class KillVirus    
3. {    
4. public:    
5.     void Operation1() { cout<<"杀毒"<<endl; }    
6. };  
7.   
8. //压缩  
9. class ZipFile  
10. {  
11. public:  
12.     void Operation2() { cout<<"压缩"<<endl; }  
13. };  
14.   
15. //加密  
16. class EncryptFile    
17. {  
18. public:  
19.     void Operation3() { cout<<"加密"<<endl; }    
20. };  
21.   
22. //刻录  
23. class BurnCD  
24. {    
25. public:  
26.     void Operation4() { cout<<"刻录"<<endl;}    
27. };  
28.   
29. //高层接口  
30. class OperatorWapper  
31. {    
32. public:  
33.     //完全功能  
34.     void MethodA()     
35.     {  
36.         KillVirus kill;  
37.         ZipFile zip;  
38.         EncryptFile encrypt;  
39.         BurnCD burn;  
40.   
41.         kill.Operation1();  
42.         zip.Operation2();  
43.         encrypt.Operation3();  
44.         burn.Operation4();  
45.     }  
46.   
47.     //简单功能  
48.     void MethodB()     
49.     {  
50.         KillVirus kill;  
51.         BurnCD burn;  
52.   
53.         kill.Operation1();  
54.         burn.Operation4();  
55.     }  
56. };  
57.   
58. //测试代码  
59. int main()    
60. {    
61.     OperatorWapper op;  
62.   
63.     op.MethodA();//完全功能  
64.   
65.     op.MethodB();//简单功能  
66.   
67.     return 0;    
68. }  

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

说明：

1. 在设计初期，应该有意识的将不同层分离，比如常用的三层架构，就是考虑在数据访问层，业务逻辑层与表示层之间，建立Facade，使复杂的子系统提供一个简单的接口，降低耦合性。

2. 在开发阶段，子系统往往因为不断的重构而变的越来越复杂，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。

3. 在维护阶段，可能这个系统已经非常难以维护和扩展了，此时你可以为新系统开发一个外观类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

重构成本：高。要修改所有直接对子系统的地调用为对Façade层的调用还是有很多事情要做的。不过，现代IDE中，如果我们删除调

用层对子系统的程序集引用，那么所有这些我们需要修改的调用都能标示出来，因为编译不能通过了嘛，因此，重构的风险还不算特

别大，只是工作量着实不小。