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

基本概念的演变

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

http://mitpress.mit.edu/sicp/


Lisp 是函数式编程语言的鼻祖吧。一定要看看。

不是要跑题，还等着 庄 后面的新方案呢。:-)

SICP这本书不错，而且翻译者也可以被信任。建议可以看看。
实际上我很怀疑庄某最后还是跑不出SICP的框架，如果是这样，那么其理论的价值就要打折扣了。

OO 概念非常之广，简单地说是现实世界的一种简化映射。

OO的出现是为了重用，这是OO的精华。

OO本身并没有脱出结构化编程的概念，这从OO的汇编可以看出，实际上一种语言的自我进化，描述世界仍然可以用最初级的语言，只是累点儿。

现在在讨论的应该是是否有更好的东西来描述世界，更快，更方便，相对于OO。如果存在这种东西，往往还需要OO的语言来实现，那也可以说是OO描述了这个世界。

OO可以简化为结构化＋代码生成＋动态地址，实际上在C＋＋中也是这样实现的，毕竟C++是由C来完成的。

目前比较重要的是选择一种既有的成熟方法来描述世界，然后进行大量地描述转换工作。

OO实际上引出了人们对现实世界的类型定义，这个类型是研究了实际对象后的一种总结，现实世界中只存在于实际对象，类型定义是人们后来加上去的，甚至类型定义本身也是一个实际对象（有点绕了，不过确实如此）。

但OO的问题不在于是否有足够的表现力，而在于是否太复杂了，从基本对象开始定义起到最终的系统定义，OO要描述和经历的过程实在是太复杂了，相对于图是不够简洁的。但是如果base on 库，就不一样了，这就是为什么类库会层出不穷。但是非标准的类库又带来另一个问题，歧义和兼容性问题，这就是OO带给人们的混乱和复杂。

如果想象一下，现在世界上有这么一个类库，将世界中的大部分对象已经作了描述，公开在网上，并且允许在一个标准委员会监督下进行公开修改。所有的人都使用这个类库描述，那么软件系统实际就相对简化了。比如开发一个考勤卡系统，从网上下载考勤卡相关对象，建立一下相关对象的逻辑关系，使用持久化技术存入持久化数据库，使用界面关联技术直接呈现界面，使用域逻辑技术编写域逻辑，一个软件就OK了。

所以标准化类库才这么地受人关心，因此也指出一个问题：任何一种描述世界的方法都是如此。

比如人类自然语言，我们有字典来解释每个字或词的含义，用上下文来确定具体含义。又比如UML，用例图来确定有用的事情，而含义则是借助自然语言，那么其实UML偷了一个懒，又或者是重用了一下自然语言，所以会觉得用例图是那么地贴切，实用。

DSL(Domain Specific Language)的描述也是类似，用一种领域内通用或熟用的描述语言来描述这个领域的事情，并且用转换器来转换成代码或计算机能识别的描述。DSL借助的是该领域内的通用字典，并且使用大量的自然语言约定，社会共识等等，将其规范化和标准化，使计算机可以直接使用。这可以说是一种重用也可以说是一种偷懒，毕竟重用节省了工作量。

ROR(Ruby on Rails)就很多地利用了这种约定俗成，比如缺省表名是类名的复数形式，缺省框架就拥有CRUD功能，引用类的关系定义方便等等。并没有创建什么新的东西，但连在一起就是一个全新的框架，并且实用性相当地好。

来描述一个软件系统，那么使用C也好，JAVA也好，汇编也好，都可以做到，但只有真正实现了标准类库或者说标准定义库才能使这件事情做得快而方便，可以真正地被企业所应用，被客户所接受。JAVA的成功，从某种角度来讲也是得益于其全面而标准的JDK类库。DELPHI的成功...多种例子。

UML存在这种问题，即没有提供标准UML库，这样阻碍了UML的普及和实用。UML中的重用是比较困难的，基本上拷贝贴粘，而没有实现象OO那样的重用机制，因此建立标准定义库也是艰难的，另外细节描述上也存在了大量问题。但主要的问题在于用UML描述细节实在是太累了。如果想象一下UML实现了重用和标准定义库，那么我们现在要做什么？从网上继承一下某UML库，挑几个画一下关系就完成了设计，不要太简单哦！

SQL和关系型数据库的成功就在于此，为什么这么多年还是甩不掉RDBMS？ORACLE为什么还是要出现？OODBMS已经不错了，但还是代替不了。就是因为SQL标准。一个大部分数据库都会偏差的SQL标准还统治并且将继续统治持久化存储领域很多年。想象一下假如有一种标准化OO库，公开，标准，象维基百科一样，那么OO描述的生存力将超过SQL，甚至RDBMS可能在一夜间死去，仅作为一种历史再翻出来看看。

任何一种可扩展，重用的描述基本上依赖于标准化库的建设，有优良的标准化库和成熟的应用的支撑会让这种描述走得更远。而成熟的应用也是因为优良的标准化库而产生的。

另外，还有一点，简洁也是非常重要的。UML的流行不是因为复杂，而是因为简洁，实际上这九种图相当地简洁，人们就是想追求一种简洁而信息含量大的描述方法，所以选择了UML。但是简洁与细节描述是死对头，这要借助于标准化库来作桥梁，UML现在使用部分自然语言和社会约定来作标准化库，估计以后使用DSL或其他描述来建立标准化库。

一个理想的标准化库的建议跟维基百科是很类似的，最初的库除了描述方法的定义什么都没有。任何人可以公开地修改库，当一个标准类型定义比较成熟的时候，正式进入该库，经过一段时间地积累，产生了一系列标准类型定义来指导软件系统，这时候其他的描述定义需要参照这个标准化库来转换成自己的描述定义。

象现在的JAVA，可以充分建立类库，将软件系统中需要描述的对象都建立进去。这样OO的描述基本上可以生存很多年，并且将成为事实标准。而观察现在EJB的定义都打仗这么长时间，估计这种标准类型库建起来太难了......(时候觉得SUN一家公司开发也有好处，至少不会象C++这样太多的类库，反而无用，标准化组织好象一直都只会拖后腿，民主这个东西实在太容易伤害自己了。)

查阅类库是我们应该做的工作吗 ? 这和翻阅TC的函数库没有多少本质区别 ?

真正好的思想需要我们在做细节工作时去考虑整体的设计吗 ? 重构 迭代 是开发软件所必须的吗 ?

这是OO永远也做不到的

1 最底层的开发人员可以随意用任何语言. 可以按照自己的喜好和习惯 写不写注释也无所谓.

2 做项目的从设计到实施基本不用编码 不需要了结类和函数. 集成的时候不用不用查看代码 不用重构 不用迭代 只做测试和拼装.

如果楼主的论调也和你一样，文章肯定会脱靶，最后变得不知所云。

我们可以假设某牛人终于有一天写出了某个很nb的系统，这个系统nb到开发软件只需要输入一句话，例如：我要一个很nb的windows软件，该nb系统就会自己计算出并生成你想要的软件。

那么这个很nb的系统跟OO有什么关系吗？一点关系都没有，这个系统可以用汇编、C或者任何其他语言来写。但我们可以确定的是写这个系统的过程中一定会用到某种方法，可能是PO、OO或者是其他被称为XO的东西。现在要研究的是为了写出这个nb系统，我们应该采用哪种方法？PO？OO？还是其他的XO？如果你用PO写出了这个很nb的系统，然后说OO不能如何如何，这就是胡扯，PO能干的OO一样能干，并且会干的更好，当然你喜欢用PO是你的问题。那么我们最后强调的是能不能写出这个nb系统跟是否采用了XO一点关系都没有。

怀念失落的世界(1)

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

我不明白什么是PO ! 我可以保证我们说的是两回事. 你可以看看netkernel. 可以利用xml改变软件的开发方式. 从面向对象这个相对抽象的层次进入到 无需"编程"无需建模直接取得"结果"这样的程度.

我知道你在说什么，在积累了大量的开发经验之后，我们总是会发现“模式”这种东西反复出现在系统当中，当掌握了足够多的信息之后，可以将这些模式高度抽象并以系统模块或者其他方式固化下来，在业务实例化的时候只需要填写相应的配置参数及业务信息即可。但是如何捕捉并固化这些模式实际上已经超越了OO所处的层次，OO解决的是更低层的问题，所以从这种角度去评论OO是毫无意义的。

楼上的可千万别乱解释啊 ! 那可偏了108000里

模式是无法兼容的 但用语言和文字组成的文档是可以兼容的

模式是相对稳定 但文档是灵活的多变的.

我的意思是抛弃数理模式 完全以文档为中心 建立程序间的藕合.

程序之间的连接 就像人类使用的语言一样 简单自然.

现在的模块是函数 类 这些东西都含有数理逻辑, 要调用它必须知道其内部的数理逻辑 所以要将他们整合是很复杂的.

如果现在的模块只是对特定的文档进行操作 输出处理后的文档. 文档中又不包括数理模型和逻辑. 那么只要知道需要提交什么文档 得到什么文档 就可以了.

利用组件对文档进行处理的时候 先后次序 流程都无所谓 只要能得到需要的文档就可以了.

所以我认为"xml编程" 会逐渐把我们带近一个不用关心OO的时代.