Pattern也要"与时俱进"

马丁叔叔发表了一篇blog, 谈OOPSLA2004的情况:
http://martinfowler.com/bliki/OOPSLA2004.html

比较有趣的是, 他参加了一个研讨会, 主题是修改GoF(10年多了, 是应该好好改改了), 会上投票讨论哪些patterns将会被咔嚓掉, 结果是:
Factory Method, Bridge, Flyweight 和 Interpreter 这4个patterns被判死刑,
而Singleton 和 Chain of Responsibility 被判死缓. 

在轻量级IoC容器流行的今天, 原先这些干粗活, 糙活的pattern代码都被容器以更好, 更优雅的方式接管了, 这样的pattern翘辫子是迟早的事情, 

这个故事这让偶想起了新闻联播里老念叨的"与时俱进", hoho

readonly你还没有分析完，最后Martin还被Anders在搞dotnet的ORM而struck

Singleton第一个该咔嚓。Fowler也说不知道那些哥们干吗不投这一票，还让它给活了下来。

可是singleton还是有它需要的场合，即使你用轻量级的容器来管理所有的组件，可你的容器总该是singleton的吧，或者是注册到一个"singleton"的管理组件中（jmx,jndi...），似乎无法避免，或者哪位有更好的方案避免singleton？

我才没那么麻烦呢，直接放进一个static field了事，全部eager initialization，多省事，何必搞什么Singleton。

这个方案和singleton没有本质的区别吧，没有解决singleton带来的“不爽”之处：不是完全面向对象的解决方案，无法享受到oo带来的好处（继承，多态...）

仅仅容器而已，其他的对象都交给容器管理了呀。难道你还要给容器搞搞继承和多态不成？

如果我的容器创建的策略是不同的，比如说最简单全部加载，或是有自动跟踪配制文件变化，重新加载，甚至是像AppServer那样能够hot deploy，这样的情况我还真的需要继承，重载，多态呢。

另外，其实你的解决方案实质上是一个简单的“静态工厂”。如果你能接受静态工厂的方式为什么不能接受singleton的方式呢，除了多两行代码，在解决这个问题的范畴内没有什么本质的不同。或者说优势不明显。

Spring有一个……叫什么来着，BeanFactoryAware？这么一个接口。你实现这个接口，不管bean factory是怎么初始化的，你总可以从setBeanFactory方法得到一个bean factory。如果需要别的加载策略，总之调用setBeanFactory方法就对了。

说穿了我就是不想去实现一个singleton。singleton对普通应用对象的损害应该不用再讨论了，至于像咱们现在讨论的这种少数情况，我就是不喜欢而已，也没别的什么原因。

这个消息很有意思。 不过对这句话准确吗？ martin 的原文是：
Most of the others were voted off because people felt they were sufficiently uncommon and that other patterns would probably take their place, sadly we didn't have time to consider new members.

martin 的意思似乎是： vote off 的原因主要是不常用。应该用另外的更加常用的进行替换。