JSF的加减法与Seam(二)之对java的改进

[quote]
题记：Seam对开发的简化，对各种不同软件的统一能力，我想其主要来源不是创造了conversation域，不是使用了元注解，不是依赖于JSF，不是使用了反射机制，而是一种更加全局的域管理机制。那些其它因素都是为了这一目的服务的，或多或少的使这一目的的实现变得更加方便可靠。如果说Seam有什么决定性的区别于其它框架的东西，那就是它的全局域管理机制。

说明：1楼和2楼铺垫了很多基础的东西。如果没有耐性，可以把它们略过去，直接从第3楼读起。
另： 文章里的命，生命周期(lifecycle)，上下文(context)，域(scope)在这里指同一内容，可以互相替换。
[/quote]

不说Seam诞生的大环境和Seam产生的语言基础，只是说Seam本身的功能，大概也可以，不过我认为非常多的外在功能都只是某些环境外在因素和基本内在因素所决定了的。大环境和内在可能定了之后，细节的东西只是做就可以了。所以没有办法，还是得绕开Seam本身说些题外话。

JSF的加减法与Seam（一）[url]http://www.iteye.com/topic/137027[/url]大概说了一下 Seam诞生的环境，这是外在机会，是融合各种技术的可能性，是广的纬度。 这篇文章说说java上的可能性，是何让Seam具有了融合的本事，是内在能力，从深的纬度上说吧。

其实也不深，因为说JAVA，其实得从最基本的说起：

1. Java 对象的命

1.1 概述
这个命呢，就是生命周期，就是什么时候生下来可以用它，什么时候死了不能再用了。一个对象在内存中的时间和生命周期是不一定相等的，因为即使一个对象完全没有办法再用了，它仍然可能还在内存里。比如[code]
void doIt() {
Object o = new Object();
o = null;
}
[/code]
这个方法执行完了之后，o是没办法再用了，但是o可能仍然还在内存里，因为内存的垃圾回收有延时，术语叫做best effort，意思就是我尽我最大能力去回收了，但是回收回得来回不来，得看情况。这篇文章里说到的生命周期，是不考虑这个延时的，如果我没有办法再用这个对象了，我就认为它已经死掉了。

1.2 假如无状态
我举一个非常理想化的例子，假如java的所有的对象的都不能有状态，那对生命周期会有什么影响呢？
如果没有状态，那么所有对象都只能用方法调用。假设我有类A,B,C；而a,b,c是它们的对象。底下老这么说费事，凡是大写都是类，凡是小写都是对象。而a.getB()则假设a有属性b并且有它的getter和setter方法。
如果所有对象的状态不能改变，则只能是这样：

[code]
public static void main() {
A a = new A();
a.doSomthing();
}
class A() {
doSomething() {
B b = new B();
b.doSomething();
}
}
class B() {
doSomehing() {
C c = new C();
c.doSomething;
}
}
[/code]

每个对象都得在某个方法里被创建（出生），而且必须在那个方法内被销毁（死亡）。那么所有的对象的生命都是和调用它的方法一样长的。这样产生了一个现象就是所有的被调用的对象一定比调用它的对象的命短，而且它出生于调用它的对象出生之后，死亡于调用它的对象死亡之前。 我们把一段生命周期称为“域”，则前者存在的域一定被包含在后者存在的域中。
如何断定的呢？ 因为调用者的那个方法的域（也就是命，也就是生命周期）一定包含于调用者本身存在的域──因为任何时候我调用那个方法，拥有该方法的那个对象一定存在，否则该方法也就不能存在了（静态方法是特殊情况等会再说）。而被调用者存在的域一定被包含在调用者方法的域中，这刚才已经讨论了。所以：
对于任意 a通过它的方法doXYZ()来调用b来说：
b的域 包含于（被包含） doXYZ()的域， 而 doXYZ() 的域 包含于 a的域。
由此可知 b的域包含于a的域。
以此类推，如果a调用b,b调用c,c调用d…… 那么后者的域总是被包含在前者的域里，也就是说越成为被调用者，命越短，越成为调用者，命越长。且被调用者存在时，调用者必然存在。