相对于面向过程的开发方法，面向对象通过退一步，海阔天空。最频繁地用来表达人类认知或描述的自然语言中的主谓结构在面向对象的形式系统中得到充分的映射。这种形式系统具有极大的语义构建能力。我甚至能够想象如果加上模糊逻辑的应用，任何系统的构建都将不成问题。因为它几乎具有完美的语义构建能力。如果再加上启发式搜索，恐怕连强人工智能也不是没有可能的！
传统的开发方法在其形式系统的语义表达能力上存在的极限被称为语言鸿沟，因为从那些系统到自然语言间存在巨大的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容器）。
面向过程。。过程的形式化语义==计算，，，“计算”机？，，。运行时语义？
来源：oschina
链接：https://my.oschina.net/u/109289/blog/34265