不要滥用单例模式

      单例模式,就是一个类只有一个实例。一开始接触这种设计模式时,我非常兴奋,在系统范围内,一个类只有一个对象,对象的唯一性可以解决计数器问题,比如扫雷游戏的剩余雷数计数;还可以解决计时器问题,比如扫雷游戏里的时间计时。另外,它还可以解决配置文件管理问题,比如管理扫雷游戏等级、雷数配置。单例模式的好处和使用范围非常广,但是,我必须告诉你,不要滥用单例模式。

      单例模式有一个严重问题,就是扩展性很差,我见很多博文都没有说到这点。就拿扫雷游戏来说吧,如果你把扫雷的剩余雷数计数用作单例,并且你已经在系统范围内多处使用到这个类了,有一天,你老板说,再搞个计数器,把玩家左右键点击次数也记一下,你可能会想,好的,再往计数器里面增加个左右键计数的属性。如果这样想,就会出现一个大问题,你的计数器移植性大大降低了,因为你这个类已经业务化了,当移植到别的程序时,别的程序并不需要你这些业务。你或许,会有另一个想法,好的,我再建个单例,把左右键点击次数记下来,这个想法就比上面的想法好多了,但是,还是有问题,既然已经有个类在计数了,何必再多出一个类呢?这不是浪费内存又浪费存储空间吗?还增加了代码量,管理起来又有诸多不便。那该怎么办呢?

       如果没有把雷数计数当做单例,这个问题就好办了,你可以生成多个对象,用于不同的计数就好了。问题是,雷数计数可以不做成单例吗?答案是肯定的,因为我们只需要在界面或者规则中,访问雷数计数,其他地方根本不需要访问到剩余雷数。

       在实践过程中,我发现,如果一个软件系统中对于某个需求是唯一的,我们第一考虑是单例,但是,我们必须多个心眼,这个单例,将来是否需要被扩展。另外,我认为,如果一个软件系统中,对某个需求是唯一的,并且这个需求仅被几个少数的类使用,我建议不要做成单例,以便将来直接移植这个类,不要给后续开发人员造成移植痛苦(后续开发人员,必须想,为什么这个类要做成单例,它有什么特殊要求、特殊应用环境)。这个思考过程是非常痛苦的~~~

      另外,关于单例模式在技术上的问题,我就不讲了,要深入了解,就去百度或者谷歌一下~~~

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值