设计模式——享元FlyWeight

运用共享技术有效地支持大量细粒度的对象。这是GOF的设计模式里的原话。

关键点: 细粒度(使用前需要考虑是否有这个必要)，大量（运用共享解决这个可能存在的问题）。

怎么共享：首先将对象属性切分成内外部2份。切分办法1，相同属性外切。C++里可以使用类静态常量保存，安全实用又方便，这个不是享元， 我们姑且叫他FlyShare。切分办法2，不同属性外切，使用时设置，当外部属性规律性很强时，这个模式才起作用，比如GOF的设计模式里举的例子：编辑器里的26个字母用享元实现。这里内部状态就26种，一个字母一个类，外部状态呢？这里的外部状态包括字体及位置。这2个外部属性是存储在字块[注1]里的。字块包括行对象，行对象设置字母的位置属性，字体属性由块对象保存。比如我这篇文档，到文档二字这里仅仅一个块对象，其字体就是宋体5号。对象数量确实大量减少了。如果这是一篇英文，不算标点才27个对象，不使用享元那么就上百个对象了，篇幅越大，效果越明显。

再举一个反面例子帮助理解，秦晓波的《设计模式之禅》里举的享元例子。将考生的注册信息用享元实现。相同信息：考试地址及科目。不同信息：考生ID，邮寄地址。享元是把不同信息外切，使用时再设置。那么我要问，考生ID和邮寄地址存在哪里？还不是一个考生一个对象，对象数量一个都没有少，该书例子里用一个哈希表实现，用相同信息作健。不同信息作值，形如：MashMap<String, SignInfo>。对象数量一个没减少还说是享元，只是一个简单的共享罢了。模式不是用来套的，呵呵。

另外多线程也是享元需要解决的问题，主要是同步问题。相反，相同属性外切的FlyShare办法无需忧虑多线程问题，因为这些共享属性都是只读的。具体来说，就以GOF的编辑器为例，如果考虑多线程，就不应该使用享元了，细分到块就可以了，不是一个字符一个对象。再说了，我们中文字符远非26个啊。

写这篇日记，一来是记录自己的心得，二来是提醒自己尽信书不如无书。设计模式真不是套的。

[注1] 块: 我杜撰的一个对象，就是具有相同字体的相邻字的一个集合。

尹彬

2010年10月25日21:34:35