面向对象的运行时特性分析+面向对象与内存

相对于面向过程的开发方法，面向对象经过退一步，海阔天空。最频繁地用来表达人类认知或描述的天然语言中的主谓结构在面向对象的形式系统中获得充分的映射。这种形式系统具备极大的语义构建能力。我甚至可以想象若是加上模糊逻辑的应用，任何系统的构建都将不成问题。由于它几乎具备完美的语义构建能力。若是再加上启发式搜索，恐怕连强人工智能也不是没有可能的！

传统的开发方法在其形式系统的语义表达能力上存在的极限被称为语言鸿沟，由于从那些系统到天然语言间存在巨大的GAP。面向对象经过填平这个鸿沟，完全地解决了计算机形式系统的表达问题。缘由是其具备很是强的认识论基础：对象。因此，说哲学没用的真的是值得好好反思。没有哲学的话，有哲学的话，差异不是通常的大：人类正常认识的途径是向前看。哲学是向后看。方向不一样，看到的东西就不一样，结果天然就不一样。

可是这是从开发方法的角度所讨论的面向对象。也就是说，它的确是一种很是好的开发方法。它固然同时也是一种很是好的建模方法。这更进一步意味着使用它所构建出来的系统与真实“世界”将更接近（由于它与人类语言的表达方法更贴近。而“世界”其实存在于语言中）。这种模型（人脑模型与计算机模型二者）上的一致性给我带来一种莫大的安全感与温馨感，由于：

1，运行时变得很是透明且很是容易理解。系统运行时对我来讲不再是不可捉摸的了。我做为一个系统的“读”者，将再也不承担在形式系统与天然语言即人类知识模型间的翻译工做。由于面向对象的系统完全移除了形式系统与人类语言间的语言鸿沟（至于在当前编程语言中仍然存在的部分语义学问题，它本质上实际上是一个语言问题，不是面向对象方法论的问题。它存在，是由于语言的设计者或编译器的设计者没有承担他们应该承担同时也只有他们可以承担的责任------大部分这类问题都是一种服务问题，而服务固然是语言的问题。好比volatile问题，它原本属于语言自己应该内“涵”的服务而不该该以一种语法元素出现），实现了（即形式化了）几乎所有的语义元素，我能一眼就看出系统当前的状态。由于系统如今有状态了而且状态就摆在那里（面向过程的系统没有状态。要了解这种系统的状态必须将大脑中没有被形式化的主语与畸形的形式系统结合起来而后通过大量思考才能获得---套用一句时髦的话：这“不够人性化”）等着我去看；

2，基于对象的运行时系统更“紧凑”。这个紧凑的意思不是指系统构件之间的依赖意义上的紧凑，而是指系统规模上的紧凑。由于不少在认识论上处于“对象”以上的语义元素如今都隐藏（被承载）在对象间的实时（动态）交互上，而不是静态关系上，因此其静态结构天然更加“紧凑”。一个更小的系统规模一般意味着更小的理解与记忆负担；

3，As long as I can keep all of the objects in good status, theoretically, the system will always be in good status too. This is apparently one very good way, at least one of the very good ways, to achieve high system stability. I mean, what I can do to make a Process Oriented system stable?... I will always  be worrying about it!

4，面向对象的系统更容易被验证。这种被验证性来自于其形式上的完整性。相比之下，面向过程的系统因为其形式上的不完整性，则基本不具有被进行形式验证的条件。由于它不是一个完整的系统，系统的另外一半位于程序员的大脑中。而谁能验证一我的的大脑？

我不想说面向对象有问题。由于它实在是太完美了。但经验告诉我，越是完美的东西，来到真实世界越可能有问题。如今就来看看它到底有什么问题。

面向对象的对象所有生存在内存中。这要求程序员具备很是强的内存编程技巧。有人可能认为程序员一直都在对内存编程，怎么可能出问题。答案是非也。由于大多数程序员在作的事情中，大部分其实并非对内存而是对数据库编程。对数据库编程与对内存编程存在巨大的差别。其中之一就在于数据库是一种很是成熟的技术，它对服务的封装很是良好，以至于即便傻瓜也很难在数据库编程上犯错误。但内存编程彻底相反。内存编程要求程序员一针到底，直捣黄龙。程序员在进行内存编程时须要直接处理内存（这本不该发生。可是面向对象每每意味着比较复杂且难以用关系模型处理的问题域。也就是说，面向对象常常用来处理的并非普通逻辑而是特殊逻辑。而这种逻辑或问题一般没有现成的方案，必须在裸机上自行建模才能解决）。缘由是如今所谓的高级语言其实并不高级，它们大多只不过是机器语言的直接翻译而已（包括运行在虚拟机上的语言）。使用这种语言进行编程与在机器上直接编程其实没有本质上的区别。由于陈述的层次并无丝毫的提高。好比“变量”只不过是对内存地址的一个别称而已。包括“赋值”与“循环”这样的语义，它们仍然是机器级别的语义，离机器基本上都是0距离（语义上的）。

在机器上编程要求理解并能控制机器。这对于应用程序程序员固然是一个问题。并且是一个很大的问题。程序员有问题，老板便天然也有了问题：老板被逼迫聘请经验更丰富的程序员。这提升了软件开发的成本。得，一分钱一分货，使用面向对象之后，质量是更好了，但价格也更高了。因而那些无状态的编程方法便跳入了眼帘。

如函数式编程由于剔除了变量，使得系统中果然只剩下纯粹的“计算”（“计算机”终于名符其实了）。这样的结果是，系统只能提供一种语义：计算。这种语义服务比面向过程的语义服务显然更加干净利索。由此也能够看出，它将拥有比面向过程更大的问题：它把一切都当成了计算。这比面向过程的把一切都当成过程错得更离谱，更远。所以它不是解决方案。一个可能的方案必须是一个至少去除了全部的同步语义但保留了面向对象语义承载能力的形式系统。FP把状态都剔掉了，对象如何可以“存在”？？

为了提升产品质量或开发难度而把状态剔除掉，与倒洗脚水连孩子（或别的东西）一块儿倒掉是一个道理。

I mean, if you're really developing some kind of systems which are really only about computing or calculation, then FP is the best choice. But that is obviously not all the cases. For example, what you can do with FP when you're required to design a realtime multiplayer game? ...

语义转换是很困难的。形式系统能够工做，是由于咱们给它赋予了与它的天然特性相符合的语义。语义替换固然是可能的，但那并不能在全部情形下工做。事实上，根据语义自己的精确性，在绝大多数状况下的语义替换都不是彻底可行的。至于具体的可行度，则由语言做为一种形式系统其解释者的容忍度决定。

由此能够看出，也许不久的未来面向对象对于大多数程序员将再也不是问题，但至少目前仍然是个问题。

对程序员的高要求只是一个方面。还有一个方面是内存容量。前面提过，面向对象的系统是紧凑的系统。但这种紧凑只是指其静态结构上的紧凑，不是规模上的紧凑。由于对于那些须要大量对象的系统，系统将可能很容易就达到很大的内存规模。事实上，这正是目前许多面向对象系统的当前状态。在这样的系统中，适当地实施必定的持久化策略（不是缓存。由于缓存是一个以持久层为中心的概念------它不属于面向对象范式中的词汇）就显得颇有必要。能够考虑将这样的系统放在一个提供持久化服务的容器中（如EJB容器）。

面向过程。。过程的形式化语义==计算，，，“计算”机？，，。运行时语义？