开放原子开发者工作坊

//该回帖还没有进行重构, 各位随便看看便罢.

直接说点我的看法吧.., 程序/软件到目前为止, 还是围绕数据展开的, 而且受到数据的制约, 这并不因为OO而改变. 但我这么说, 很明显的, 不是说我赞成应该使用DataSet. DataSet只是用来简化数据结构的一种手段, 就像数据库是提取数据结构共性从而简化数据结构更基本的手段. 这根本不涉及到模型这些. Martin把什么表入口/领域模型等等做横向比较, 不是不可以, 但这里头存在一个误导, 就是把它们变成了一个问题的两种实现方式, 甚至包含对立的意味在内.

用不用RecordSet (比如DataSet)这种形式, 关键在于, RecordSet是否能够简化数据结构方面的工作. 如果以更高层次反过来看, 这只是数据源+DataSet代替了单纯的数据源. 然后是DTO, DTO实际上只是一种帮助我们更好的工作的另一种手段, 和RecordSet没有本质区别, 但这并非是它应该受到攻击的原因.

然后才轮到是用不用建模啊之类问题, 如果根本无需建模, 那么就成为了你们所攻击的那种方法, 含有DTO或者简单的行数据组成的集合, 直接进入了其它层次. Martin也承认有个成本问题, 关键是他做了错误的比较, 把纵向的多个层次中根据不同情况省略了其中某几个层次后, 造成的不同表现形式, 作为几种方法进行了横向的比较, 这就偏离了实质.

我不是学院派, 但是印象里OOA也有个问题域吧. 大多数程序员不是哲学家或哪怕哲学的初学者, 所以总是过于着眼于更具体的东西. 其实是你的问题, 决定是否建模, 是否在接近数据源的地方存在RecordSet, 等等等等. 那谁谁不是自己说过, 计算机科学, 就是通过增加一层去解决原有问题的一门科学, 本来这些都是不矛盾的, 最后让Martin这么一起头, 加上国内外的Jdon/Javaeye们推波助澜, 变成了在各种具体情况下非此即彼的论战.

国内的程序员总是过于崇拜国外的一些大 嘴, 毕竟人家先起的步. 但是计算机科学, 尤其是现代的软件科学, 还是很不成熟的一门科学, 所以没有什么是想当然正确的, 无论发言者是谁. 在我看来, 如何编写"对的"程序, 只有通过不断的思考, 有了自己的理解才做的到. 为什么我说Jdon他们都钻牛角尖钻歪了, 因为他们用很多大嘴的言论在很大程度上作为了公理, 那么推导的时候, 必然限制自己思维的发挥. 这么多年过去了, 连DP95的作者都承认, 很多原来提出的概念存在不少谬误, 这还不说明问题么?

对我来说, GoF的DP95这样的作品是真正的经典, 因为他们精确的提出了很多存在于软件开发领域的问题, 开宗明义的说明了他们的方法从什么角度以什么程度解决它们; 而后来的这些人, 包括Martin, 包括很多很多Martin一伙的家伙, 在著书立传的时候, 由于选取的话题包含的内容过于繁复, 导致他们的论证过程只是在他们自己给出的例子上走个形式, 根本不具有真正的普适性.

反过来比较Gosling和Anders这两个家 伙, 就知道为什么Java社区始终是一个热闹的社区(热闹, 气氛好, 一大堆新奇概念, 不代表就有一个对的方向), 却最终升起了RoR这么一个骑墙派且残废的明星. 这个地方我不多说, 你可以上网查查Anders的访谈, 看看C#是不是真的只是一个Java的复制版本，那些一个又一个的不同的设定是如何考虑的。从我的角度看，由于缺乏创造Turbo Pascal/Dephi这样的经历，注定了Gosling永远做不到像Anders那样思考的广度和深度，只能当个学院派； 再反过来看看现在，到底是谁还在继续从事技术工作，就会明白差距到底在哪里。

是的我承认，由于微软的糖豆太多，很多.NET开发人员躺倒下来不去进行深入的思考；但从另一个方向上看，在一个错误的开端和基础上，永远只能无限接近而不能达到正确的结果；同时，每个人都参与方法论的讨论，这个真的有必要么？

.NET 代表的是什么路线? 不需要太多的人去思考，最终那些最先进的观念，由很少的人提出， 但所有的人都会用(虽然现实还差很远)。这“很少的人”不是指微软那帮子， 而是指整个.NET社区中的少数人，但这种风格和微软做了某物然后大多数人用是一脉相承的， POO(在这里P不是指Program, 指Producer)永远是少数，这也是效率最高的方式。

但是我们得等到这种结构变得真正成熟, 才能看见他的威力。POO们自然会去吸收Java社区中被证明是对的那些结论，也会去吸收Rail等实用框架的优势。POO们的高高在上，也注定了. NET社区和类似的社区永远不会在Java社区的那些话题上热闹起来。Java社区的存在有必要么? 在我看来，Java社区是不可或缺的，因为实际上是他们在为所有真正的POO(无论是.NET/Java/其他的)提供那些停留在低层次的但又不得不进行 的反复权衡。

你可以看看类似于Lucene这样的项目，可以快速的移植到.NET上，这些项目的繁荣其实并不说明Java社区的优势，而 仅只是Java社区对整个开发社区的贡献。起点的不同决定了角色的不同，就好比Sun创造了Java而IBM获益一样。这就是为什么在我看来Martin 这样的，只不过是一个低层次社区中讨论的带头人，永远也成不了一个真正优秀的POO; 所以我不得不提醒一下.NET领域里对这些方面有兴趣的爱好者，即使是印成了黑纸白字的言论，你我阅读的时候也必须再三斟酌，二次创作。

比 如什么“领域模型需要尽量接近现实世界”的言论。其实面向对象的书里头把人的思维往错误的地方引导的东西特别多。比如车/奔驰车/开车的这个例子。很明显 的，车还可以分解成引擎/车身/传动；引擎还可以分解成缸盖/缸体；缸体是由铁铸的。那么铁相当于Int32之类的，于是就成了什么基本型迷恋。这个提 法其实和RecordSet是一样的。

不是说基本型迷恋不存在，或者说基本型迷恋是对的，关键是大多数人连问题域都找不准，让他分辨 什么是基本型迷恋，最终造成的是什么都像是基本型迷恋（或类似的问题)，我个人就曾经经历过这个过程， 甚至现在还得有意克服一下：你生产的明明是一个缸体，就是把铁(基本型或者RecordSet）送进设备(其他逻辑)里加工成缸体， 而缸体本身就是制作引擎(其它调用者甚或就是界面)真正需要的结果， 却怎么也感觉不对劲， 愣要把铁先变成一个自加工的不知道是什么东西(因为这种东西根本就不应该存在)的东西， 否则就浑身不自在。

在我看来，Javaeye上 的多数热火朝天的讨论，在所谓的“接近现实世界”的时候，实际是背离了世界，因为连对象都没找准(这个基本功，却是Martin他们根本没教过—我甚至怀 疑他是否掌握的够好，而各种哲学/科学类书籍里反复讨论的)，这是因为没有切割出正确的概念，和没有划分出正确的问题的缘故。