梦话对象之一：逃不开的生死问题

序：近期读一奇人写的系列文章，其中从哲学和数学角度论证了很多问题，读其文章的时候回味技术，也觉得有很多相通的地方，于是也就梦话一次，娱乐一把。

通常我们都认为世界是三维的，因此对于世界万物都可以使用数学建模来抽象和考虑。但实际在此观点上我们遗忘了一个客观存在的东西：时间。将时间考虑进来，那么世界就变成了一个四维的空间。世间万物都有生死，只要其在世界上存在过，则必然对应时间轴上的相应长度，并且在另外的三维空间中存在一个映射。因此，看待一个问题，尤其是在那种随着时间的流逝会产生变化的物体，如果不考虑其如何生、如何维持、如何死的问题，则所看到的必然仅仅只是其在某个时间点的映射。这就如盲人摸象一般，自以为已经看到了全部，而实际仅仅只抓住了其一部分特征。

上面的论述，个人认为适用于一切随时间流逝而导致状态变化的事物。例如对技术来说，即使简单于我们操作的一个对象，都应该去考虑其生死和延续问题。对象的构造器，让其能够获得新生；对象的析构器，则构成了其灭的基础；中间的状态变化，只是灭之前的维持，是为了完成在系统中所赋予的使命。当其灭之后，又构成了其他对象生的基础，因为其释放了相应的内存空间。一个个对象就是在这样的生死循环中，构成了我们的业务逻辑，帮助我们模拟现实中的问题。

即便是在设计模式中，也有不少模式是为了解决对象的生死而存在的。比如创建型模式，就是解决对象的生的问题。对象有简单和复杂之分，简单对象可以直接通过new创建出来；几个自相似性的对象则可以通过工厂模式来创建；而一个复杂对象，则可以通过builder模式来一步一步的创建。对象灭的问题，在非托管中比较统一，使用析构函数即可。但在托管代码中，就有了IDisposable模式，用于处理使用了非托管资源的托管对象的灭的问题。

上面说的基本是一个对象的生命周期。而对于一个业务系统，其核心是其中所包含的各种业务逻辑。随便抽出一条业务逻辑，其必然包含一个流程（原理是计算机的线性处理），而该流程就是为了改变相关业务对象（或领域对象）的状态，或者构成相关领域对象的灭。举个例子：如果我们有这样的一台服务器，其内存无限大，并且24*7的供电。那么当某个用户注册的业务逻辑在这台服务器上实现之后，就是在该服务器上创建了一个该用户的对象，并为其分配相应的一部分内存，这就构成了该用户对象的生。而只要这个用户不被删除，那么该块内存应该一直为该用户对象所占用，其中可能会有一些状态的变化，比如帐号余额的变动，但无论如何，这块内存不能为别的对象所用；这就构成了该用户对象的维持。当这个用户最终被删除，那么该块内存被释放，这就构成了该用户对象的灭。而现实中，由于不存在这样的服务器，由于服务器内存有限，存在断电情况，所以将内存中的对象保存到数据库中，这种操作被称之为对象的休眠，也就是Java中的ORM工具Hibernate（中文意为休眠）的名称的由来。不过必须注意的一点，就是new一个对象并不一定代表一个对象的生，比如从数据库的休眠状态中还原回来的对象，并不构成这个对象的在业务过程中的生，其仅仅表示将这个对象从数据库中唤醒。当然，从对象到数据库映射的这个角度来考虑，则可以将每次唤醒的对象都看做该对象的新生。

对象的本质是对万物的抽象，而万物的生死投影到时间上是一个动态的过程。因此系统设计中如果不去考虑生命周期的因素，那么所看到的仅仅只是某个时间点上的对象状态，其是静态和不完整的，因为其维持和消亡的过程被无意的忽略掉了。