Singleton和Static的缺点

Singleton和Static的最重要缺点就是失去了面向对象的多态特性。

在项目中,一个用户在操作一条纪录时需要上锁，防止别人同时操作。
然后我们写了一个LockManager,在数据库里一个表写上某条纪录被某个人锁。
由于这个东西相当于Service一样，也不需要多件，所以我们把它写成了
Singleton 类，调用LockManager.lock() 和LockManger.unlock() 方法。
后来经过考虑，如果Server不是Cluster,只是一个JVM的话
那么只需要在Server维护一个内存锁，而不需要访问数据库。
这个实际上是一个不同的锁策略，两种方法是锁策略的不同实现，
然而由于我们已经把Lock作成Singleton,调用代码已经与LockManger 这个class耦合,无法透明替换不同实现。
  所以这就是Spring的一个好处，从ApplicationContext取回来的Bean既可以是Singleton，也可以是Prototype,而该Bean是正常的类，具有正常的类的特性。
  (虽然重构一下，LockManager delegate到不同的LockStragety实现就可以了，
不过从这个例子确实体会到Singelton不是什么好东东：)，一用就耦合与具体的类了，
还是从Spring取比较好，在Runtime再决定到底是不是Singleton。

呵呵，每一种设计模式都有其特定的适应范围和优缺点，泛泛地去谈论缺点似乎意义不大。

指的是spring的可配置性吧，其实你自己也可以把SINGLETON写成这样，SPRING这方面也没用什么先进技术，只是最佳实践吧

凤舞凰扬说的对，每种设计模式都有其适用的场合，GOF 等大师也从来没有想过提供一种包治百病的模式出来。在不适合的场合滥用设计模式就是过度设计或者邯郸学步了。关键还是找到应用设计模式适当的时机。我认为对业务充分的理解后就是一个很好的时机。在刚开始不理解业务时就用设计模式是不好的。

具体问题具体分析说到底只不过是一句空话。
关键是场合是什么？范围又是什么？中国人从老祖宗哪代就开始讲"看菜吃饭，量体裁衣""到什么山上 唱什么歌"，可惜总也没有分析出坚船利炮来。有兴趣的刻意去看看这个[url]http://bbs.chinacourt.org/index.php?s=9c424b6933f76ec5fa1e65b3f776bc02&showtopic=32671
[/url]

为什么说不过是一句空话呢？
照这样说，那么你到这个论坛来发的言，岂不是大多都是空话？

我的楼上Trustno1这位朋友感觉有些奇怪了，也看了他留的URL。
   我不太清楚这位朋友究竟是怎么想的？也不清楚现在做到了哪一个层次，好像什么东西都要大家给一个明确的答复似的。
   要明确的答复完全可以，把环境，把条件给好，大家完全可以告诉你哪样更好，哪样相对不好。但是我相信每一位经验丰富层次比较高的朋友绝对不会盲目地去比较一样东西。如果这样，都被楼上“讥讽”为哲学诡辩的话，我就实在不解楼上的真正意图以及为人了。
    我相信来论坛讨论技术的朋友，无非是两种，一，解决具体的问题，这个时候需要具体的回复；二，大家的思维想法进行交流讨论，彼此成长，技术这东西是没有绝对谁对谁错的，只是能说在特定情况下，哪个相对更好，相对更合适。如果楼上又拿什么所谓哪些是特定，哪些关键场合。我可以告诉你，什么都是特定，什么都是关键场合。
   你不觉得这样的提问如同大家在讨论对象关系的时候，被问起哪个实例会怎么样，哪个实例是具体，那岂不是太好笑了？？？

哈哈，我喜欢Trustno1的调调，那篇关于屁的link实在是太好玩了。

"呵呵，每一种设计模式都有其特定的适应范围和优缺点，泛泛地去谈论缺点似乎意义不大。"， "具体问题具体分析" 这种中庸之道的话初看起来很有道理，但是谁都会说，就是屁话了。

还是极端的想法带来给我带来的头脑风暴更有趣。


从第2贴开始就离题了，我最讨厌这种离题的讨论了，那么就让我带回主线吧，pico的开发人员甚至认为Singleton是antipattern：
http://docs.codehaus.org/display/PICO/Singleton+antipattern

蛮有道理的说

ok, 此话题到此为止,我锁掉了。希望大家言之有物。
本来任何技术都有缺点，但是请大家冷静发言。不希望这里成为CSDN第二。如有继续的技术讨论请另外开帖。