外观模式及其改进（三）：外观类的单例化

由于外观类维持了对多个子系统类的引用，外观对象在系统运行时将占用较多的系统资源，因此需要对外观对象的数量进行限制，避免系统资源的浪费。可以结合单例模式对外观类进行改进，将外观类设计为一个单例类。通过对外观模式单例化，可以确保系统中只有唯一一个访问子系统的入口，降低系统资源的消耗。单例化之后的外观模式结构如图6所示：

图6  单例外观类结构图

      在图6中，外观类Facade被设计为单例类，在其中定义了一个静态的Facade类型的成员变量instance，其构造函数为私有的(private)，通过一个静态的公有工厂方法getInstance()返回自己的唯一实例。

      实例改进：

      为了节省系统资源，可以将图3中的EncryptFacade设计为单例类，改进之后的结构图如图7所示：

图7  单例化改进之后的文件加密模块结构图

【在图7中，我采用UML衍型(Stereotype)对模式角色进行了标注，大家也可以这么标注结构图中的模式信息，挺方便的，】

      在图7中，EncryptFacade类的实现代码如下： 

[java] view plaincopy

1. public class EncryptFacade {    
2.     private static EncryptFacade instance = new EncryptFacade();    
3.     private FileReader reader;      
4.     private CipherMachine cipher;    
5.     private FileWriter writer;      
6.         
7.     private EncryptFacade() {    
8.         reader = new FileReader();          
9.         cipher = new CipherMachine();    
10.         writer = new FileWriter();      
11.     }    
12.         
13.     public void fileEncrypt(String fileNameSrc, String fileNameDes) {    
14.         String plainStr = reader.read(fileNameSrc);    
15.         String encryptStr = cipher.encrypt(plainStr);    
16.         writer.write(encryptStr,fileNameDes);       
17.     }      
18.     
19.     public static EncryptFacade getInstance() {         
20.              return instance;       
21.     }    
22. }    

      在上述代码中使用饿汉式单例实现EncryptFacade类，确保系统中有且仅有一个EncryptFacade类的实例，从而避免生成多个EncryptFacade对象，节约系统资源，提高程序性能。

 

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

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

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

      (3) 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。【下次再结合Struts等框架的设计，写一篇文章来专门讨论这种情况，

【作者：刘伟   http://blog.csdn.net/lovelion】