从各种资料上我们知道享元模式的特点有:
1.对象是细粒度的, 比如字符串(python的短字符串对象就是这样设计的), 数字类别这样, 而不是{attr1, attr2, attr3 ....}这样的
2.内部状态是稳定的, 数量不多, 经常重复, 比如黑白棋的黑色子与白色子
3.外部状态都不一样, 棋子的位置.
然后享元模式的核心就在于工厂方法.每次被请求创建对象的时候,通过判断池子里面有没有来决定是否产生新的对象,进而达到节约内存的目的.
网上的很多资料介绍到这里也就结束了, 但是这样留给我这样的初级读者的却是一个极大的错误认识---那就是内存是大量的节约. 为什么这样说呢, 就拿刚才的黑白棋的例子来说, 如果棋盘上有100个棋子, 我们认为只产生了2个棋子对象(黑子和白子), 然后位置通过参数传递. 这样内存对象的压缩率就达到了98%.
但是学过信息论的同学都知道, 就算使用各种神奇算法来编码压缩也逃不过香农定律的极限.然而通过上面的直觉估算,反而是信息越多,压缩比越高,比如10000000个棋子那么几乎是100%的压缩比了. 造成这个结果的原因就是我们一直在关注共享内部状态,而忽视了外部状态的管理.
我就以一款以前玩过的游戏--三国志来说:
故事设定---一个中级将领可以带领100个纯种兵员, 要么全是步兵, 或者全是骑兵, 或者全是象兵.在对打开始时(初始化), 100个兵出现在10*10的方阵中, 打的过程中还有可能死掉. 所以我们就用享元模式表示做这个战斗过程中士兵对象.
大一刚学编程的我是这样写:
class Soldier{
private type; //infantry
private cor_x;
private col_y;
private is_alive;
}
我们假设每个属性都是一个字节,那么100个士兵就需要400 bytes的存储.
a.按照我最初对享元模式的理解,那么压缩比是99%
b.按照围棋设计方案,我们把位置和死活剥离出来
class Soldier{
private type; //infantry
public void display( new Is_alive_and_position oooo);
}
class Is_alive_and_position{
private cor_x;
private col_y;
private is_alive;
}
这样的话,100个士兵就有1个Soldier对象和100个Is_alive_and_position对象,占用内存是:
1*1 + 100*3 = 301, 压缩比是25%
c.我们把种类和死活作为基础共享类,然后位置对象剥离处理:
class Soldier{
private type; //infantry
private is_alive;
public void display( new Position oooo);
}
class Position{
private cor_x;
private col_y;
}
占用内存:2 * 2 + 100*2 = 204, 压缩比是50%
d.我们进一步剥离,把横坐标也作为基础类的属性, 因为只有1~10:
class Soldier{
private type; //infantry
private is_alive;
private cor_x;
public void display( new Position_y oooo);
}
class Position_y{
private col_y;
}
这时,活的基础士兵有10个,死的也有10个,共享类有20个. 在纵向的位置类有100个,所以
内存:20*3 + 100*1=160, 那么压缩比是60%
通过上面的对象压缩比来看: 99%> 60% > 50% > 25%
第一个是骗人的,我们不管,
最后一个节约不多,但是设计简单,内部状态只有一个,共享对象也只能有一个
60%节约最多,但是共享类设计稍微复杂,而且共享对象也有20个
以上的分析是不考虑程序执行耗时, 真实内存状态的. 只是建立一个模型来分析. 享元模式的重点不是享元工厂的设计,而是结合程序环境, 内存节约度, 程序执行效率, 类和对象管理复杂度来设计享元类和外部类. 这就好比在我们使用react或者vue.js时,核心的虚拟DOM树并没有减少必要的真实DOM操作,只是优化的执行过程.