敲响OO时代的丧钟！——DJ对于数据持久化的支持(3)

to:ozzzzzz
说说你对“一切都是对象”的理解吧。

你对我、徐昊、Gigix、老曹等等等等人的失望，我不太明白。你上面的这篇文章，我也没看明白。

你说：只要是使用名词法就不可能做到《一切都是对象》
那么，动词也是对象、副词也是对象、形容词也是对象、代词也是对象、介词也是对象、如此等等，一切能够说出的语言中的每一个词都是对象？

你想说的是这个意思吗？

但是我一直有个疑问。
DBC看起来缺乏一个定义真并发语义的办法，因此并不适合于企业级开发的真实场景。或者说，遵循DBC构建起来的系统，作为并发系统是不牢靠的。

本来想今晚上看起的，但发现如果要看懂，我还得从哲学开始补起。 没10年苦功不行啊。
   看来，这东西不属于技术人员的事。如果理解这么一个OO的终结以及新的语言诞生需要那么多高深的知识，那么，我们应该从儿童抓起。

（正文：对象的类型提升和下降是一个仍在不断研究中的课题。）这句话也出现在本书的第一版里，它就像20年前一样正确。开发出一种有用的，具有一般意义上的框架，以描述不同类型对象之间的关系（这在哲学中称为本体论)，看来是一件极其困难的工作。10年前的混乱和今天的混乱的主要差异在于，今天已经有了一批各式各样的并不合适的本体论，他们已经被嵌入到数量过多而又先天不足的各种程序设计语言中。举例来说，面向对象语言的大部分复杂性----以及当前各种面向对象语言之间的细微而且使人迷惑的差异---的核心，就是对类型之间通用型操作的处理。我们在第三章关于计算性对象中完全避免了这个问题。熟悉面向对象的程序员将会注意到，第三章的局部状态说了许多东西，但是根本没有提到类，和继承，事实上，我们猜想是，如果没有知识表示和自动推理的工作的帮助，这些问题无法仅仅通过计算机语言的设计的方式合理的进行处理。

对象模型对世界的近似在于将其分割为独立的片断，函数式模型则不是沿着对象间的边界去做模块化。当对象间部共享的状态远远大于它所共享的状态时，对象模型就特别好用。这种对象观点失效的一个地方是量子力学，在那里将物体看作独立的粒子就会导致悖论和混乱。将对象观点和函数观点统一起来可能与程序设计关系不大，而是与基本认识论有关。

这SICP就要年年看、月月看、天天看，每道习题、每个注脚都要认真看。

凡是觉得自己在软件设计上有啥洞见的，请先翻阅SICP。如果SICP上写了的，说明你生不逢时；如果SICP没写，基本上可以断定你是错的。

SICP的两个注脚，我认为很有点意思。手边没有书，凭记忆写下来，大家回头可以自己去查。第一个貌似是注118（第二章，“继承多边形”那个图的下面）：

在设计大型系统时，处理好一大批互相有关的类型而同时又能保持模块性，这是一个非常困难的问题，也是当前正在研究的一个领域。

Dealing with large numbers of interrelated types while still preserving modularity in the design of large systems is very difficult, and is an area of much current research.