问单例模式

EN

http://sites.google.com/site/steveyegge2/singleton-considered-stupid

为什么单例如此吸引人？我会第一个承认:我也喜欢它。不，算了吧--我喜欢单例。从我看到它的那一刻起，它就像一个老朋友。它是简单而美丽的。

我来告诉你为什么:这是因为单例模式是对非面向对象编程的一种回归。对于那些连“四人帮”想说的话一个字都听不懂的人来说，这是一条生命线。我不知道它是怎么进来的--毫无疑问是一些政治上的OOPSLA压力--但它不属于那里。是邪恶的..。

这是一个“简短”的总结。

a)我甚至还没有涉及到十分之一的问题。但我会说出其中的几个。

b) One是内存管理；如果在一段时间内没有人会使用它，那么它基本上只是一个内存泄漏。但是您不知道何时释放它，因为没有人会打电话给您并说“在一段时间内没有人会使用您！”

此外，你不知道是谁保留了对你的单例实例的引用，因为你对分发它相当无动于衷，不是吗？(注意:Java的弱引用可以帮助解决这个问题)。

c)说到内存泄漏，如果你的单例拥有某个有限资源的句柄，比如数据库或文件句柄，该怎么办？我想你可以在你的程序结束之前一直保持这种状态。谢天谢地，C++程序永远不会在崩溃前超过10分钟，通常是因为资源耗尽，或者是因为试图访问某人释放的单例。

Ruby )另一个问题是单例设计在语法上很繁琐；大多数语言都不支持它(不幸的是，支持，但那可能是在Matz知道更好之前)，所以你不仅要在单例中使用样板代码，而且要在每个使用它的人中使用它。

e)，然后是子类化的事情。几乎不可能对Singleton进行子类化，如果您做到了这一点，那么您一开始就不应该使用Singleton。你甚至都不想去那里。我走过一些我不敢再说的路。只要假装你做不到，你就会为自己省去惊人的痛苦。

f)静态方法像granite一样灵活。每次你使用一个，你的程序的一部分都是具体的。只要确保当你看着它变硬的时候，你的脚不会卡在里面。有一天，您会惊讶地发现，您真的需要那个该死的PrintSpooler类的另一个实现，它应该是一个接口、一个工厂和一组实现类。哦！

不要以为这就是全部。还有很多其他的问题。例如，尝试在中添加多线程，看看会发生什么。好吧，我告诉你会发生什么:一半的时间里，你会得到一个Doubleton或Tripleton，除非你是一个同步专家，而拥有一个Tripleton就像有三个Balrog出现在你的茶话会上一样令人向往。即使你是一位同步专家，并且掌握了正确的复查习惯用法，你仍然有一个Balrog需要处理，而且它们不是一件容易的事情。

但与大问题相比，这些问题都显得微不足道了，因为OO很难，程序化很容易，所以单例“模式”会鼓励你忘记所有关于OO设计的知识……

如果您有这样一种情况，即只需要一个对象来协调整个系统的操作，那么您可以使用此模式。外观就是一个很好的例子，也就是说，外观可以实现为单例，因为整个系统通常需要一个外观对象。

但总的来说，这通常是一种糟糕的做法，应该避免，一个很大的原因是它极大地抑制了可扩展性。

Java Runnable是单例模式的最佳示例。当您想要添加一个限制，该限制不允许您为特定类创建多个单实例时，最好实现单例模式。实现单例的要点：

• Private Constructor
• Static类的私有实例getter变量itself
• Public getter方法只有在第一次初始化时才会初始化上述变量，并且总是返回同一个Singleton类的实例。

类单例{私有静态单例实例；私有单例(){}公共静态单例getInstance(){ if(instance=null){ instance=new Singleton()；}返回实例；} ........}

为了线程安全: getInstance()需要为synchronized.