设计模式：享元模式Flyweight（转）

      面向对象的思想确实很好地解决了抽象性的问题，以至于在面向对象的眼中，万事万物一切皆对象。不可避免的是，采用面向对象的编程方式，可能会增加一些资源和性能上的开销。不过，在大多数情况下，这种影响还不是太大，所以，它带来的空间和性能上的损耗相对于它的优点而言，基本上不用考虑。但是，在某些特殊情况下，大量细粒度对象的创建、销毁以及存储所造成的资源和性能上的损耗，可能会在系统运行时形成瓶颈。那么我们该如何去避免产生大量的细粒度对象，同时又不影响系统使用面向对象的方式进行操作呢？享元设计模式提供了一个比较好的解决方案。

公共交换电话网的使用方式就是生活中常见的享元模式的例子。公共交换电话网中的一些资源，例如拨号音发生器、振铃发生器和拨号接收器，都是必须由所有用户共享的，不可能为每一个人都配备一套这样的资源，否则公共交换电话网的资源开销也太大了。当一个用户拿起听筒打电话时，他根本不需要知道到底使用了多少资源，对用户而言所有的事情就是有拨号音，拨打号码，拨通电话就行了。所以，就有很有人会共用一套资源，非常节省，这就是享元模式的基本思想。

假如我们要开发一个类似MS Word的字处理软件，下面分析一下将如何来实现。对于这样一个字处理软件，它需要处理的对象既有单个字符，又有由字符组成的段落以及整篇文档，根据面向对象的设计思想，不管是字符、段落还是文档都应该作为单个的对象去看待。我们暂不考虑段落和文档对象，只考虑单个的字符，于是可以很容易的得到下面的结构图： 

 1//抽象的字符类
 2
 3public abstract class Charactor{
 4
 5    //属性
 6
 7    protected char letter;
 8
 9    protected int fontsize;
10
11    //显示方法
12
13    public abstract void display();
14
15}
16
17//具体的字符类A
18
19public class CharactorA : Charactor{ 
20
21    //构造函数 
22
23    public CharactorA(){
24
25          this.letter = 'A';
26
27          this.fontsize = 12;    
28
29    }
30
31    //显示方法
32
33    public override void display(){
34
35        Console.WriteLine(this.letter);
36
37    }
38
39}
40
41//具体的字符类B
42
43public class CharactorB: Charactor{ 
44
45    //构造函数 
46
47    public CharactorB(){
48
49          this.letter = 'B';
50
51          this.fontsize= 14;    
52
53    }
54
55    //显示方法
56
57    public override void display(){
58
59        Console.WriteLine(this.letter);
60
61    }
62
63}
64
65

我们的这段代码完全符合面向对象的思想，但是却为此搭上了太多的性能损耗，代价很昂贵。

一篇文档的字符数量很可能达到成千上万，甚至更多，那么在内存中就会同时存在大量的Charactor对象，这时候的内存开销可想而知。

我们对内存中的对象稍加分析就能发现，虽然内存中Character实例很多，但是里面有很多实例差不多是相同的，比如CharactorA类的实例就有可能出现过很多次，这些不同的CharactorA的实例之间只有部分状态不同而已。那么，我们是不是可以只创建一份CharactorA的实例，然后让整个系统共享这个实例呢？直接使用显然是行不通的。比如一份文档中使用了很多的字符A，虽然它们的属性letter相同，都是'A'，但是它们的fontsize却不相同的，即字符大小并不相同。显然，对于实例中的相同状态是可以共享的，不同的状态就不能共享了。  

为了解决这个问题，我们可以变换一下思路：首先将不可共享的状态从类里面剔除出去，即去掉fontsize这个属性，这时候我们再写一下代码： 

 1//抽象的字符类
 2
 3public abstract class Charactor{
 4
 5    //属性
 6
 7    protected char letter;
 8
 9    //显示方法
10
11    public abstract void display();
12
13}
14
15//具体的字符类A
16
17public class CharactorA : Charactor{ 
18
19    //构造函数 
20
21    public CharactorA(){
22
23      this.letter = 'A';
24
25    }
26
27    //显示方法
28
29    public override void display(){
30
31        Console.WriteLine(this.letter);
32
33    }
34
35}
36
37//具体的字符类B
38
39public class CharactorB: Charactor{ 
40
41    //构造函数 
42
43    public CharactorB(){
44
45      this.letter = 'B';
46
47    }
48
49    //显示方法
50
51    public override void display(){
52
53        Console.WriteLine(this.letter);
54
55    }
56
57}
58
59

经过这次重构，类里面剩余的状态就可以共享了，下面我们要做的工作就是要控制Charactor类的创建过程。如果已经存在了“A”字符这样的实例，就不需要再创建，直接返回实例；如果没有，则创建一个新的实例，这跟单例模式的做法有点类似了。在单例模式中是由类自身维护一个唯一的实例，享元模式则引入一个单独的工厂类CharactorFactory来完成这项工作：

 

 1 //享元类工厂
 2 
 3 public class CharactorFactory{
 4 
 5     private Hashtable charactors = new Hashtable();
 6 
 7     //构造函数
 8 
 9     public CharactorFactory(){
10 
11         charactors.Add("A", new CharactorA());
12 
13         charactors.Add("B", new CharactorB());
14 
15     }
16 
17     //获得指定字符实例
18 
19     public Charactor getCharactor(String key){
20 
21         Charactor charactor = charactors[key] as Charactor;
22 
23         if (charactor == null){
24 
25             switch (key){
26 
27                 case "A": charactor = new CharactorA(); break;
28 
29                 case "B": charactor = new CharactorB(); break;
30 
31             }
32 
33             charactors.Add(key, charactor);
34 
35         }
36 
37         return charactor;
38 
39     }
40 
41 }
42 
43 

经过本次重构，已经可以使用同一个实例来存储可共享的状态，下面还需要做的工作就是要处理被剔除出去的那些不可共享的状态。缺少了这些不可共享的状态，Charactor对象就无法正常工作。

解决对象中不可共享状态的问题

      我们先考虑一种比较简单的解决方案：对于不能共享的状态，不要在Charactor类中设置，而是由客户程序在自己的代码中进行设置：

 1 //客户程序
 2 
 3 public class ClinetTest{
 4 
 5         public static void Main(String[] args){
 6 
 7         Charactor a = new CharactorA();
 8 
 9         Charactor b = new CharactorB();
10 
11         //显示字符A
12 
13         display(a,12);
14 
15         //显示字符B
16 
17         display(b,14);
18 
19     }
20 
21  
22 
23     //设置字符的大小
24 
25     public void display(Charactor objChar, int nSize){
26 
27         Console.WriteLine("字符：" + objChar.letter + "，大小：" + nSize);
28 
29    }
30 
31 }
32 

按照这样的实现思路，可以发现如果有多个客户端程序使用的话，会出现大量的重复性的逻辑,就像上面这段代码中的display方法一样，需要所有的客户端都提供，因此，这段代码已经出现了臭味，非常不利于代码的复用和维护。另外，把这些状态和行为移到客户程序里面破坏了面向对象中封装的原则。

所以，我们再次转变我们的实现思路，把这些不可共享的状态仍然保留在Charactor对象中，把不同的状态通过参数化的方式，由客户程序注入。以下代码是我们最终实现的一个版本：

  1 //抽象的字符类
  2 
  3 public abstract class Charactor{
  4 
  5     //属性
  6 
  7     protected char letter;
  8 
  9     protected int fontsize;
 10 
 11     //显示方法
 12 
 13     public abstract void display();
 14 
 15    //设置字体大小
 16 
 17     public abstract void setFontSize(int fontsize);
 18 
 19 }
 20 
 21 //具体的字符类A
 22 
 23 public class CharactorA : Charactor{ 
 24 
 25     //构造函数 
 26 
 27     public CharactorA(){
 28 
 29       this.letter = 'A';
 30 
 31       this.fontsize = 12;    
 32 
 33     }
 34 
 35     //显示方法
 36 
 37     public override void display(){
 38 
 39         Console.WriteLine(this.letter);
 40 
 41     }
 42 
 43     //设置字体大小
 44 
 45     public override void setFontSize(int fontsize){
 46 
 47         this.fontsize = fontsize;
 48 
 49     }
 50 
 51 }
 52 
 53 //具体的字符类B
 54 
 55 public class CharactorB: Charactor{ 
 56 
 57     //构造函数 
 58 
 59     public CharactorB(){
 60 
 61           this.letter = 'B';
 62 
 63           this.fontsize= 14;    
 64 
 65     }
 66 
 67     //显示方法
 68 
 69     public override void display(){
 70 
 71         Console.WriteLine(this.letter);
 72 
 73     }
 74 
 75     //设置字体大小
 76 
 77     public override void setFontSize(int fontsize){
 78 
 79         this.fontsize = fontsize;
 80 
 81     }
 82    
 83 }
 84 
 85 //客户程序
 86 
 87 public class ClinetTest{
 88 
 89     public static void Main(String[] args){
 90 
 91         Charactor a = new CharactorA();
 92 
 93         Charactor b = new CharactorB();
 94 
 95         //设置字符A的大小
 96 
 97          a.setFontSize(12);
 98 
 99         //显示字符B
100 
101         a.display();
102 
103         //设置字符B的大小
104 
105          b.setFontSize(14);
106 
107         //显示字符B
108 
109         b.display();
110 
111     }
112 
113 }
114 
115 

可以看到这样的实现明显优于第一种实现思路，这就是享元模式的基本思想。我们通过享元模式实现了节省存储资源的目的。


什么是享元模式
      享元的英文是Flyweight，它是一个来自于体育方面的专业用语，在拳击、摔跤和举重比赛中特指最轻量的级别。把这个单词移植到软件工程里面，也是用来表示特别小的对象，即细粒度对象。至于为什么我们把Flyweight翻译为“享元”，可以理解为共享元对象，也就是共享细粒度对象。享元模式就是通过使用共享的方式，达到高效地支持大量的细粒度对象。它的目的就是节省占用的空间资源，从而实现系统性能的改善。
      我们把享元对象的所有状态分成两类，其实前面的例子中letter和fontsize属性在运行时，就形成了两类不同的状态。
      享元对象的第一类状态称为内蕴状态(Internal State)。它不会随环境改变而改变，存储在享元对象内部，因此内蕴状态是可以共享的，对于任何一个享元对象来讲，它的值是完全相同的。我们例子中Character类的letter属性，它代表的状态就是内蕴状态。

      享元对象的第二类状态称为外蕴状态(External State)。它会随环境的改变而改变，因此是不可以共享的状态，对于不同的享元对象来讲，它的值可能是不同的。享元对象的外蕴状态必须由客户端保存，在享元对象被创建之后，需要使用的时候再传入到享元对象内部。我们例子中Character类的fontsize属性，它代表的状态就是外蕴状态。  

所以享元的外蕴状态与内蕴状态是两类相互独立的状态，彼此没有关联。
类图：
       

• 抽象享元类（Flyweight）

      它是所有具体享元类的超类。为这些类规定出需要实现的公共接口,那些需要外蕴状态(Exte的操作可以通过方法的参数传入。抽象享元的接口使得享元变得可能，但是并不强制子类实行共享，因此并非所有的享元对象都是可以共享的。

• 具体享元类(ConcreteFlyweight)

      具体享元类实现了抽象享元类所规定的接口。如果有内蕴状态的话，必须负责为内蕴状态提供存储空间。享元对象的内蕴状态必须与对象所处的周围环境无关，从而使得享元对象可以在系统内共享。有时候具体享元类又称为单纯具体享元类，因为复合享元类是由单纯具体享元角色通过复合而成的。

• 不能共享的具体享元类(UnsharableFlyweight)

      不能共享的享元类，又叫做复合享元类。一个复合享元对象是由多个单享元对象组成，这些组成的对象是可以共享的，但是复合享元类本身并不能共享。

• 享元工厂类(FlyweightFactoiy)

      享元工厂类负责创建和管理享元对象。当一个客户端对象请求一个享元对象的时候，享元工厂需要检查系统中是否已经有一个符合要求的享元对象，如果已经有了，享元工厂角色就应当提供这个已有的享元对象；如果系统中没有适当的享元对象的话，享元工厂角色就应当创建一个新的合适的享元对象。

• 客户类(Client)

      客户类需要自行存储所有享元对象的外蕴状态。

实现和使用享元模式需要注意的问题

      面向对象虽然很好地解决了抽象性的问题，但是对于一个实际运行的软件系统，我们还需要考虑面向对象的代价问题，享元模式解决的就是面向对象的代价问题。享元模式采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。

      在具体实现方面，我们要注意对象状态的处理，一定要正确地区分对象的内蕴状态和外蕴状态，这是实现享元模式的关键所在。

      享元模式的优点在于它大幅度地降低内存中对象的数量。为了做到这一点，享元模式也付出了一定的代价：

1、享元模式为了使对象可以共享，它需要将部分状态外部化，这使得系统的逻辑变得复杂。

2、享元模式将享元对象的部分状态外部化，而读取外部状态使得运行时间会有所加长。

另外，我们还有一个比较关心的问题：到底系统需要满足什么样的条件才能使用享元模式。对于这个问题，我们总结了以下几条：

1、一个系统中存在着大量的细粒度对象；

2、这些细粒度对象耗费了大量的内存。

3、这些细粒度对象的状态中的大部分都可以外部化；

4、这些细粒度对象可以按照内蕴状态分成很多的组，当把外蕴对象从对象中剔除时，每一个组都可以仅用一个对象代替。

5、软件系统不依赖于这些对象的身份，换言之，这些对象可以是不可分辨的。

      满足以上的这些条件的系统可以使用享元对象。最后，使用享元模式需要维护一个记录了系统已有的所有享元的哈希表，也称之为对象池，而这也需要耗费一定的资源。因此，应当在有足够多的享元实例可供共享时才值得使用享元模式。如果只能够节省百八十个对象的话，还是没有必要引入享元模式的，毕竟性价比不高。

什么情况下使用享元模式
      享元模式在一般的项目开发中并不常用，而是常常应用于系统底层的开发，以便解决系统的性能问题。

      Java和.Net中的String类型就是使用了享元模式。如果在Java或者.NET中已经创建了一个字符串对象s1，那么下次再创建相同的字符串s2的时候，系统只是把s2的引用指向s1所引用的具体对象，这就实现了相同字符串在内存中的共享。如果每次执行s1=“abc”操作的时候，都创建一个新的字符串对象的话，那么内存的开销会很大。

如果大家有兴趣的话，可以用下面的程序进行测试，就会知道s1和s2的引用是否一致：

.Net代码:

 1 String s1 = "测试字符串1";
 2 
 3 String s2 = "测试字符串1";
 4 
 5 if( Object.ReferenceEquals(s1, s2) ){
 6 
 7     Console.WriteLine("两者一致");
 8 
 9 }
10 else{
11 
12     Console.WriteLine("两者不一致");
13 
14 }
15 

程序运行后，输出的结果为“两者一致”，这说明String类的设计采用了享元模式。如果s1的内容发生了变化，比如执行了s1 += "变化"的语句,那么s1与s2的引用将不再一致。

至于Php作为一种弱类型语言，它的字符串类型是一种基本类型，不是对象。另外，它的执行方式与Java和.Net也有明显区别，每一个脚本文件执行开始，将会装入所有需要的资源；执行结束后，又将占用的资源就立即全部释放，所以它基本上不会产生类似的性能问题，它的字符串处理的设计，自然也使用不到享元模式。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wanghao72214/archive/2009/04/03/4046182.aspx