ps:这是敏捷软件开发，原则模式和实践的读书记录。
以下是bob大叔所列出的Singleton模式的好处和不足。
好处：
跨平台：使用合适的中间件（例如RMI），可以把Singleton模式扩展为跨多个JVM 多个计算机工作（此处我还不能够理解）。
适用于任何类：只需要把一个类的构造函数变成私有的，并且在其中增加相应的静态方法和变量，就可以把这个类变成Singleton（我感觉这一点提的非常好）。
可以透明派生创建：给定一个类，可以创建它的一个Singleton子类。（我还没有过这方面的实践，有机会我要试一下）。
延迟求值：如果Singleton从未使用过，那么就决不会创建它。
不足：
摧毁方法未定义：没有好的方法摧毁一个Singleton，或者解除其职责。即使添加一个decommission方法把the instance置为null，系统中的其它模块依然持有对该Singletion实例的引用。这样，随后对instance方法的调用创建另外一个实例，致使同时存在个实例。这个问题在C++中尤为严重，因为实例没有被摧毁，可能会导致去提领，一个已经摧毁的对象。(Bob大叔说的这个到是不是一个问题呢？如果我们的Singleton返回的是一个对目标对象的Wrapper的话，那么效果又会怎么样呢？初想一下可能会实现一种已经释放到的旧对象到新创建的新对象之间的无逢转变）。
不能继承：从Singleton类派生出来的类并不是Singleton。如果要使其成为Singleton,必须要增加所需的静态方法和变量（对此我没有实践过）。
效率问题：每次调用Instance方法都会执行if语句。就大多数调用而言，if语句是多余的（这个一般不会成为问题，可以使用语言本身提供的静态初始化功能完成，事情上bob大叔下面举的例子也正是使用java的静态初始化功能来完成的）。
不透明性：Singleton的使用者知道它正在使用一个Singleton，因为它们必须调用Instance方法（Bob大叔说的好，这实际上也是一种耦合，只不过造成的问题一般情况下不会怎么严重罢了）。
以下是bob大叔所列出的Singleton模式的好处和不足。
好处：
跨平台：使用合适的中间件（例如RMI），可以把Singleton模式扩展为跨多个JVM 多个计算机工作（此处我还不能够理解）。
适用于任何类：只需要把一个类的构造函数变成私有的，并且在其中增加相应的静态方法和变量，就可以把这个类变成Singleton（我感觉这一点提的非常好）。
可以透明派生创建：给定一个类，可以创建它的一个Singleton子类。（我还没有过这方面的实践，有机会我要试一下）。
延迟求值：如果Singleton从未使用过，那么就决不会创建它。
不足：
摧毁方法未定义：没有好的方法摧毁一个Singleton，或者解除其职责。即使添加一个decommission方法把the instance置为null，系统中的其它模块依然持有对该Singletion实例的引用。这样，随后对instance方法的调用创建另外一个实例，致使同时存在个实例。这个问题在C++中尤为严重，因为实例没有被摧毁，可能会导致去提领，一个已经摧毁的对象。(Bob大叔说的这个到是不是一个问题呢？如果我们的Singleton返回的是一个对目标对象的Wrapper的话，那么效果又会怎么样呢？初想一下可能会实现一种已经释放到的旧对象到新创建的新对象之间的无逢转变）。
不能继承：从Singleton类派生出来的类并不是Singleton。如果要使其成为Singleton,必须要增加所需的静态方法和变量（对此我没有实践过）。
效率问题：每次调用Instance方法都会执行if语句。就大多数调用而言，if语句是多余的（这个一般不会成为问题，可以使用语言本身提供的静态初始化功能完成，事情上bob大叔下面举的例子也正是使用java的静态初始化功能来完成的）。
不透明性：Singleton的使用者知道它正在使用一个Singleton，因为它们必须调用Instance方法（Bob大叔说的好，这实际上也是一种耦合，只不过造成的问题一般情况下不会怎么严重罢了）。
