真是滑稽,application本来就是单例,里面放的东东是按名访问的,只要名字是一个,不用管放在里面的对bean是否实现了单例。
a页面:
|
b页面:
|
类MyObj:
|
访问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。
我是这个意思,大概语言表达太差没说明白。
所以,单例也是有前提场景的,如果状态是被整个应用共享,那么就是整个应用scope范围的单例,但是如果这个应用部署到多个JVM,你如何实现呢?改变部署运行环境,scope又不一样,结论也不一样。
所以,怎样去判断一个类只能有一个实例,这个命题有点像伪命题,没有单纯意义上实例,只有某个scope下的单例,所以,认真研究对象生命周期才是最关键的,每当我们new 一个class类时,就要想到它的生命周期是怎样。
好在:现在有那么多技术支持,已经不是一个太难的题目,EJB/Spring/seam等框架帮助我们管理无状态的实例;对于有状态的,大部分是业务类,那么Evans DDD也提供仓储和工厂等方法帮助我们控制生命周期。
感觉教材能够提供一个比较,比较用了某个设计模式的好处,那就最好了。不过这个要求好像对写书的人太苛刻了。
小程序员,小公司,代码写的很难看。加个新功能比较烦。