发现一个CSDN的网友，通读了这个系列的blog，我觉得我的工作没有白做。于是我想我应该继续维护这份文档。
今天想说说关于Singleton的一些事情，Singleton算是最easy的面向对象概念和设计模式之一了，我觉得我还是能讲出一些不常见的东西的。
1. C++的Singleton，
几年前，我狂热于C++的时候，写了一些自己的classes(classes，有时候可以翻译为类库，其实我本是打算写库的，但是code不够那个量级)，其中就有基于模板的Singleton。
用起来大概是这个样子的：
Singleton<MyClass>::Instance();
嗯，缺点是需要一个friend关键字的支持。但是优点是(基本)不侵入对象，因为在实际coding中，一个对象是不是一个Singleton，很难讲，以某一个App的Config对象为例，这个Config是某个系统(你可以认为是若干有关联的对象)的配置，但是后来，我们希望整个系统存在多个同类型的子系统，而Config和子系统是一对一的关系，那么这个时候，Config对象就难以独善其身了。此外，大家也都知道，Singleton的代码，千篇一律，我希望我的Code include后，开发者就只要关系对象的功能或行为就OK了。
当然了，写C++的Code建议大家用Loki的Singleton，它考虑的事情确实很多，不过用起来未必很爽。具体内容看《C++设计新思维》。在这里就不多说了，说多了也都是模板技巧。毕竟代码都很简单，问题只在线程安全问题。
2.DCL(Double Check Lock "singleton")
一般来说，保证C++ Singleton的线程安全，都是采用DCL，双检锁技术的。不列代码了，到处都是，但是你要小心了。
DCL的正确性来自于原子操作。一般来说，用C++写DCL，很容易对，Java就难以保证正确了，记得几年前，Java的DCL的例子很多，这几年都开始批驳这种代码了。根源可能在于Java的内存模型，这种模型加上诱惑，导致了DCL失效。唉，真是悲哀啊。
而在C#中，借助.Net 4.0的Lazy类，很容易写出线程安全的Singleton类。
3. Singleton is Harmful?
以上都是废话，因为那些技术和面向对象，并没有直接的关系，别忘了，我们是要做什么来的。要是你发现哪本号称讲面向对象的书，只讲实现，实现又不讲DCL的，那一定是一本残疾书。
我所以写了一个C++的Singleton，是因为，曾经我写C++Code的时候，写了很多Singleton。但是后来呢，一部分被推翻了。因为发现那不应该是一个Singleton。
以Eclipse的插件开发为例，我做过一个Notes 8.5的Sidebar，如果你没用过Notes的Sametime，你可以把他看成是IE浏览器的History窗口(不知道合适不)。当我们打开这个窗口的时候，对象就会构造一次，而关闭的时候，它们大都会Disposed。开始的时候，我以为Sidebar关掉的时候，只是简单的隐藏，而不是重新构造，于是我写了很多Singleton，和这些我认为也有很长生命周期的对象一起工作，后来，我发现了真相，于是这些Singleton，就被迫改成和这些对象有1*1关系的对象了。
嗯，说完后，我发现一点都不make sense。确实，当你遇到了，你就知道了，过早的决定一些Singleton是有害的，现在我在使用Singleton的时候，都会很小心，会考虑系统未来可能要支持的变化。所以，我宁愿写成一个普通的class，而只是创建一个对象，而提醒自己，不要再创建第二个了。
总结说来，当某个对象A和其他对象，比如说B，可能是1对1的关系的时候，由于当认定B只有单一实例的时候，我们很有可能会把A写成Singleton。但是B真的永远只有一个实例吗？不如让A同B，保持1*1的关系。这样才能在需求变化的时候，改更少的代码。
4. Singleton是模式，更是普遍存在
其实，把Singleton列为一种模式，是因为写法都相似罢。但是Singleton的存在，并非如其他的模式那样。老实说，Observer没有，也一样写代码，只是可能违反很多规则，然而Singleton是一种普遍存在的道理。说白了，对个类，是多实例(Multi-instances)，还是单一实例(Singleton)？
看看Spring，OSGi，Servlet技术本身，都提供了对Singleton(此时这个词，并不只是一个模式的名字了)的支持。没有别的，它就是自然而然存在的，必须考虑和支持。
发现一个不错的BLOG，Share一下：
http://blog.csdn.net/yuankaining/archive/2008/08/05/2770430.aspx
