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

I totally agree with age0.
I can detect some bad smells in "丧钟", we may have to refactor it.
By the way, I provide 庄表伟 some new weapons to fight with OOers.

http://c2.com/cgi/wiki?ArgumentsAgainstOop
http://xahlee.org/Periodic_dosage_dir/t2/oop.html

Criticism of OOP (http://www.geocities.com/tablizer/oopbad.htm)
Objects Have Failed (http://dreamsongs.com/ObjectsHaveFailedNarrative.html)
Arguments Against OOP (C2 wiki discussion) (http://c2.com/cgi/wiki?ArgumentsAgainstOop)
OOP Better in Theory than in Practice (http://www.devx.com/opinion/Article/26776)
Why Paul Graham is Creating a New Language Without OOP (http://www.paulgraham.com/noop.html)

原本这一篇我是打算写《设计模式批判(2)》的，但是经过权衡，我决定放弃原本的进度计划，将攻击已有技术成果的文字大大缩短，尽快开始写我的设计方案部分。因此，设计模式的批判我将改变批判的方式，不是直接空对空的批判，而是在提出了自己的设计方案之后，通过对比，向大家表明，使用新的思维模式与技术手段，原有的设计模式需要解决的问题，现在能够得到更加灵活、易懂的解决。

同样的，对于AOP、CGLIB、Mixin之类的新技术，我也将通过实际的例子证明，在我的新方案内，这些技术所带来的灵活性，同样能够自然、安全、方便的得到。

在JavaEye的讨论中，JavaCup给了我一堆非常好的地址，我会仔细去看的。初步看下来的结果是，攻击OO的语气似乎比我的还要激烈，而改进的方案基本上还是从LISP这样的角度出发的。因此我的版本应该还是有一定的新意的。

关于JavaCup所同意的age0的观点，我不敢苟同，因为按照他的逻辑，一切技术的优劣都是不存在的，有区别的，只是使用者的水平高低不同。而且，似乎firebody也持类似的观点。一种技术如果你用得不好，就该自己反省！那么，为什么我就不能也假设“OO可以被改进”呢？任何大家看得到的技术进步，不都是来自于对于已有技术的不满吗？如果人人都只知道提高自己的武功，却不去改进武器，那么大家现在为什么不是还在用“机器码”编程呢？

我明天会简单分析一下“关系型数据库对于OO的启示”，后天就打算正式开始介绍自己的新的语言设计方案。希望大家没有等得太生气

hehe,
不知道大家听说过没有另一个AOP: Agent oriented Programming.
可以看看http://www.cs.uu.nl/3apl/
还是能够有点开启思路的。这个算得上是AI中某个支流的小溪流的领先者。说句实话，lisp现在只是计算机科学中纯粹主义者的玩具了，搞ai的没几个玩它，连prolog都快没人玩了，他们的逻辑基础已经适合不了从80年代中后期出现的现代AI潮流。现在最缺乏的是一个具备逻辑内涵的真并发模型，即便是3apl至少现在也还没有搞定（好像是有想法，但一直没看到东西）。
简单的说，可以把Agent看作是具备推理/行为(包括与环境和其他agent的交互)能力的主动对象，一旦涉及到交互，这个世界就变了。或者说，这是传统AI和现代AI的重要区别之一。

我们从来不认为OO不可以被改进，也不会认为你的新思路不会有什么创新之处，只是认为OO的发展远没有到尽头，任何一种新思维都有可能以一种新的设计指导原则反映在OO上，这只会使OO体系更加完善和壮大，仅此而已。

OO能从关系型数据库借鉴些什么？

http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!292.entry

Suppose we have two tables T1, T2, T1 has a column id_t2 refer to the primary key of T2 id, if you don't know the E-R diagram and you don't look up the metedata of the database, can you identify such a relationship between the two tables?


Usually, each object has a uid.


Have you ever think of the EJBQL or JDOQL? although they are not as perfect as SQL, they are standard in JAVA world.

本来打算等庄写完以后，再来阐述我的观点。但是至少从目前看来庄表达的意思还没有超过我的预想，但是为了不去过分的打扰他的进度，我只粗略的说说我观点。希望对他能够有所启发。我不认为oo是一种信仰，于是我们就必然可以讨论其优劣。所以我支持庄对于oo进行深入思考额做法。但是我对他的看法还是又有所不同，可能还可以称为相反的观点。

oo在我看来可以用一句话来表达——一切都是对象。我不知道多少人理解了这个观点。对象按照传统的说法（也是普遍能够被认出的说法)是数据和操作的封装，或者说对象是由数据属性和操作数据结合的整体化单位。似乎数据和操作是不同的两种产物，那么又如何用《一切都是对象》来解释呢？其实SICP中已经给出了回答的线索，操作也是数据。或者说数据属性和操作其实从本质上来说是相同的，即便把AOP考虑在内，依然还是一样。

当我们用这个视角去考虑问题的时候就会由很多的不同。我曾经在csdn上做过一个关于建模的调查，结果出奇的一致，所有人都在使用名词法来进行建模。其结果证实了我的设想。然而也有些失望，因为gigix也给出了类似的答案。以我对于gigix的了解，他应该是在那个时候已经阅读过sicp了，但是他一样不能脱离名词法的束缚。

记得以前似乎是ajoo介绍了一种方法论（可能是我记忆错误了，也可能是国内的一位朋友介绍），这种观点认为世界是有一些对象和脱离对象单独存在的一些过程（或者叫方法）构成的。这种观点其实同名词法一样，对于世界的认识还是不能做到《一切都是对象》。

而徐昊的观点包括老曹的观点，一样是名词法的。只要是使用名词法就不可能做到《一切都是对象》，而使用sql来描述RMD一样不能做到统一。也就是说不管庄作任何的努力，只要他不能做到对《一切都是对象》构成的方法进行批判，其所作的努力都是白搭。因为其阐述的靶子就错了，其批判的无非还是一些不能遵守oo基本原则的非oo观点。所以其作的评比都是在给oo唱赞歌，而不是敲丧钟。而其作的任何的对于oo的改进，无非还是在原地踏步。

同时我对于徐昊的观点表示非常的失望，因为他的理解非常领我吃惊，因为我知道他也应该知道，但是他一样还是不能得到突破。实际上联系是什么呢？或者说他们推崇的ER中的联系，或者干脆的说那些数据库中的键到底是什么呢？难道键同表和表中的数据还有什么分别吗？

其实讨论了这么久，一切还是应该解决一个基本的问题——《一切都是对象》这样的视角是不是可以做到。要论证oo的错误或者叫缺陷，就必须论证《一切都是对象》究竟是不是可能。如果可能，就要论证这样的角度究竟是不是不能解释一切。至少从目前的情况看，任何人还没有对这一点作出到位的论断。
看来我还要耐心的等等下去。

这样看来，我和你的观点倒是比较接近，现在的设计都比较倾向于使用动词法，其实只要仔细研究一下“主谓宾”的句法，就不难发现谓语的广泛性和稳定性。

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

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

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

你想说的是这个意思吗？

关系这件事情，在数据库里，是有一个独立的概念的。而在OO里面，却没法有一个统一的“标识”。



如果能够做到这一点，这个对象就“完整”了。



因为OO中，对象间关系的标识没有规范，在这样的不规范的现状基础上，要开发规范的OQL，是非常困难的。EJBQL和JDOQL，只怕现在都有很多缺陷，这样的缺陷的根源，就是来源于OO没有内置的“关系标识”。