不要滥用单例模式

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

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

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

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

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