口号倒是喊得响！拿出东西来拉。

“2：对于纯粹的web应用，放在application域的对象可以用单例，它本身就是全局的，不需要多个不同的状态，只要一个一致的实例状态。”
真是滑稽，application本来就是单例，里面放的东东是按名访问的，只要名字是一个，不用管放在里面的对bean是否实现了单例。

是我表达有歧义？刚才做了一个实验：
a页面：


<jsp:useBean id="myobj" class="com.MyObj" />

<%
	String name = request.getParameter("name");
	myobj.setName(name);
	if (name.equals("first")) {
		application.setAttribute("myobj", myobj);
	}
%>

b页面：

<%
	out.print(application.getAttribute("myobj"));
%>

类MyObj:

public class MyObj {

	public MyObj() {
	}

	private String name;

	public void setName(String name) {
		this.name = name;
	}

	public String getName() {
		return name;
	}

	public String toString() {
		return name;
	}
}

访问a页：http://localhost:8080/apptest/a.jsp?name=first
访问b页：输出first
访问a页：http://localhost:8080/apptest/index.jsp?name=a
访问b页：输出first
因为操作后忘记设置回application了，（这里用name不等于first实现）
修改MyObj，将name设为static
重复以上访问步骤，最后的输出是a。
我是这个意思，大概语言表达太差没说明白。

期待你的方法

持续期待你的方法和心得，持续中……

不得不持续跟帖!!想看看你这个著名公司的人有什么著名的思想

其实没有真正意义上的单例，想想一个分布式环境，有几台服务器，你说的单例是指一个JVM的一个实例，还是整个应用的单例呢？

所以，单例也是有前提场景的，如果状态是被整个应用共享，那么就是整个应用scope范围的单例，但是如果这个应用部署到多个JVM，你如何实现呢？改变部署运行环境，scope又不一样，结论也不一样。

所以，怎样去判断一个类只能有一个实例，这个命题有点像伪命题，没有单纯意义上实例，只有某个scope下的单例，所以，认真研究对象生命周期才是最关键的，每当我们new 一个class类时，就要想到它的生命周期是怎样。

好在：现在有那么多技术支持，已经不是一个太难的题目，EJB/Spring/seam等框架帮助我们管理无状态的实例；对于有状态的，大部分是业务类，那么Evans DDD也提供仓储和工厂等方法帮助我们控制生命周期。

我是来参观著名IT公司程序员的

bang是很牛的人,学习!

不好意思，我把这件事给忘了，可能有一年没有上网了吧，我这一年都在琢磨23中经典设计模式，所以忘了上网！我是每时每刻都在琢磨设计模式的，可以说我是为DP生也为DP。。。让大家期待了一年，我都感到没脸见各位前辈，在此表示道歉和遗憾！学设计模式主要是靠悟性，没有悟性是学不好也用不好的！！！学设计模式首先应该从装饰模式入手，因为一旦你了解了该模悟道式，那么你将被设计模式所吸引，会自动自发的去专研、去悟道。我不希望初学者是个教条主义，你要多多琢磨每个设计模式的来源和思想！下次继续写，再见！我希望不是一年以后。

期待你的下文啊！？

我最近也在学设计模式，看的是banq的《java实用系统开发指南》。没什么头绪。第一章我就看了一个多星期。没什么大的感悟。
感觉教材能够提供一个比较，比较用了某个设计模式的好处，那就最好了。不过这个要求好像对写书的人太苛刻了。
小程序员，小公司，代码写的很难看。加个新功能比较烦。

不过我也不是说《java实用系统开发指南》书不好，我也找了不少设计模式的书，这本还是觉得蛮好的，主要是人笨。

设计模式绝对不是那种可以随便套用的东西，是在工作中积累然后体会出来的东西，对写程序少于三年的都不推荐看设计模式，高于三年你就是不让他用他自己也能写出几个来了，然后用理论看一遍，与过去写的程序印证一下，就豁然开朗了。要不然看了就是天书，不该使用模式的时候使用模式造成设计过度。

最近在看设计模式，被里面精巧的设计方法所陶醉，希望自己能尽快的领悟到里面的真髓！

上页
下页