前面说提到的五种创建模式,主要解决的问题是如何创建对象,获得产品。而单例模式最要关心的则是对象创建的次数以及何时被创建。
Singleton模式可以是很简单的,它的全部只需要一个类就可以完成(看看这章可怜的UML图)。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来,Singleton模式可以相当的复杂,比头五种模式加起来还复杂,譬如涉及到DCL双锁检测(double checked locking)的讨论、涉及到多个类加载器(ClassLoader)协同时、涉及到跨JVM(集群、远程EJB等)时、涉及到单例对象被销毁后重建等。对于复杂的情况,本章中会涉及到其中一些[1]
目的:
希望对象只创建一个实例,并且提供一个全局的访问点。
场景:
Kerrigan对于Zerg来说是个至关重要的灵魂人物,无数的Drone、Zergling、Hydralisk……可以被创造、被牺牲,但是Kerrigan得存在关系到Zerg在这局游戏中的生存,而且Kerrigan是不允许被多次创造的,必须有且只有一个虫族刀锋女王的实例存在,这不是游戏规则,但这是个政治问题。
分析:
如前面一样,我们还是尝试使用代码来描述访问Kerrigan的过程,看看下面的UML图,简单得我都不怎么好意思放上来占版面。

图6.1 单例模式的UML图
结构是简单的,只是我们还有一些小小的要求如下:
1.最基本要求:每次从getInstance()都能返回一个且唯一的一个Kerrigan对象。
2.稍微高一点的要求:Kerrigan很忙,很多人找,所以希望这个方法能适应多线程并发访问。
3.再提高一点的要求:Zerg是讲究公务员效率的社会,希望找Kerrigan的方法性能尽可能高。
4.最后一点要求是Kerrigan自己提出的:体谅到Kerrigan太累,希望多些睡觉时间,因此Kerrigan希望实现懒加<
留言区(共0条)