[收藏]怪怪的回复
2007-09-13 21:50 | 怪怪
@lyb
呵呵, 我确实激动了点. 关于Martin, 我不否认他对很多事情有很多贡献, 他说的话也有很多有道理的. 不过我没说清楚我对"老菜鸟"的定义:
我给他一个"老"字, 就说明我认可了他绝大多数思考, "菜鸟"的意思, 是他还缺乏真正精辟的, 入木三分的思想.
国内有很多人在骂大嘴马丁叔叔, 确实这里头有很多自不量力的, 但是也有很多是看见了Martin没看见的东西的. 甚至不向矛盾: 一个人既可以在很多方面水平不敌Martin, 但在另一些事情上有更好的理解.
我是马甲, 所以我说话不用扭扭捏捏, 我曾经说过很多遍, 我只是作为一种声音, 提醒一下每次争论中的主角, 我甚至有时候是有意让话里带刺, 以期引起重视, 我到底对别人是好意还是恶意, 我觉得只能是主角们自己体会.
直接说点我的看法吧.., 程序/软件到目前为止, 还是围绕数据结构展开的, 而且受到数据结构的制约, 这并不因为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他们根本没教过—我甚至怀疑他是否掌握的够好，而各种哲学/科学类书籍里反复讨论的)，这是因为没有切割出正确的概念，和没有划分出正确的问题的缘故。
嗯又说多了， 还是考虑自己开一个博客吧...
呵呵, 我确实激动了点. 关于Martin, 我不否认他对很多事情有很多贡献, 他说的话也有很多有道理的. 不过我没说清楚我对"老菜鸟"的定义:
我给他一个"老"字, 就说明我认可了他绝大多数思考, "菜鸟"的意思, 是他还缺乏真正精辟的, 入木三分的思想.
国内有很多人在骂大嘴马丁叔叔, 确实这里头有很多自不量力的, 但是也有很多是看见了Martin没看见的东西的. 甚至不向矛盾: 一个人既可以在很多方面水平不敌Martin, 但在另一些事情上有更好的理解.
我是马甲, 所以我说话不用扭扭捏捏, 我曾经说过很多遍, 我只是作为一种声音, 提醒一下每次争论中的主角, 我甚至有时候是有意让话里带刺, 以期引起重视, 我到底对别人是好意还是恶意, 我觉得只能是主角们自己体会.
直接说点我的看法吧.., 程序/软件到目前为止, 还是围绕数据结构展开的, 而且受到数据结构的制约, 这并不因为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他们根本没教过—我甚至怀疑他是否掌握的够好，而各种哲学/科学类书籍里反复讨论的)，这是因为没有切割出正确的概念，和没有划分出正确的问题的缘故。
嗯又说多了， 还是考虑自己开一个博客吧...
# re: 域模型向左走(充血)，向右走(贫血)
2007-09-13 22:20 | 怪怪
另外, 我说的很清楚了, 我不是在指责谁, 对你有用的, 你就该感谢我, 对你没用的, 一笑了之罢了, 我又不收咨询费不是 :)
另外感觉LZ的(别人创造的)词汇很丰富, 这正是我对大多数有志于提高自己OO水平的程序员的担忧, 这说明很多观点已经深入到你脑海里去了, 这会钳制助你的思维方式.
GoF 他们马丁他们说, 统一的词汇有助于交流, 问题是, 这些词汇所构筑的世界必须是一个可靠的世界, 否则用这些词汇和词汇所代表的概念, 只能误入歧途. 我只是提醒大家, 这个可靠性, 还远远没有得到证实. 而且很多时候明显的我们看见了更多的泥潭, 很简单的就交流的泥潭来说, 我看见你们在争论"你对词汇一的理解有问题", "你对词汇二的理解有问题"...
比如亚历山大同志所说的完美的自顶而下的设计, 也不见得就是一定的吧. 不同的工作不同的问题, 用不同的方式方法搞定, 然后组合, 再我看来才是一个比较正确的方法. 数据结构是最后设计的, 这个我也不能苟同. 现在大家在普遍强调需求, 却没有看到为什么强调: 过去的程序员最优先解决的总是如何在计算机上实现的这个问题, 而忽略了你们说的什么场景啦用例啦等等, 因为在最初关注的难点逐渐解决了以后, 就要考虑做出更好的更符合要求的设计; 所以这种强调实际上是针对老式但还没有退休的程序员的.
而我们呢, 过早的上了这些课, 就忽略了编程的本质问题. 其实不妨把计算机或者其它基础(比如你用的操作系统/平台框架/数据库)当做我们的另一个客户, 去体会体会它的需求, 因为你不考虑它们的需求, 你承担的恶果不会比忽略了真实客户的需求小的.
另外感觉LZ的(别人创造的)词汇很丰富, 这正是我对大多数有志于提高自己OO水平的程序员的担忧, 这说明很多观点已经深入到你脑海里去了, 这会钳制助你的思维方式.
GoF 他们马丁他们说, 统一的词汇有助于交流, 问题是, 这些词汇所构筑的世界必须是一个可靠的世界, 否则用这些词汇和词汇所代表的概念, 只能误入歧途. 我只是提醒大家, 这个可靠性, 还远远没有得到证实. 而且很多时候明显的我们看见了更多的泥潭, 很简单的就交流的泥潭来说, 我看见你们在争论"你对词汇一的理解有问题", "你对词汇二的理解有问题"...
比如亚历山大同志所说的完美的自顶而下的设计, 也不见得就是一定的吧. 不同的工作不同的问题, 用不同的方式方法搞定, 然后组合, 再我看来才是一个比较正确的方法. 数据结构是最后设计的, 这个我也不能苟同. 现在大家在普遍强调需求, 却没有看到为什么强调: 过去的程序员最优先解决的总是如何在计算机上实现的这个问题, 而忽略了你们说的什么场景啦用例啦等等, 因为在最初关注的难点逐渐解决了以后, 就要考虑做出更好的更符合要求的设计; 所以这种强调实际上是针对老式但还没有退休的程序员的.
而我们呢, 过早的上了这些课, 就忽略了编程的本质问题. 其实不妨把计算机或者其它基础(比如你用的操作系统/平台框架/数据库)当做我们的另一个客户, 去体会体会它的需求, 因为你不考虑它们的需求, 你承担的恶果不会比忽略了真实客户的需求小的.
# re: 域模型向左走(充血)，向右走(贫血)
2007-09-13 22:35 | 怪怪
最后要表达的一个观念是, 人能吸收的东西是有限的. Martin他们说了, 不代表咱们就不用思考, 你的精力分配到琢磨他的东西上, 你自己体会的机会就放过了. 最后陷入到各种理论的汪洋大海之中, 永远是一个追随者. 因为未来一定会出现一个B, 这个B说的比A更对, 又得吸收笑话B的, 然后还是没给自己的创造性留出时间.
大家在讨论这些阳春白雪的时候, 我觉得首先应该关注一下自身的时间分配, 别人的认识会在一定程度上增加你的技能, 但这种投资并不是最有效的(当然保险系数稍高), 编程人员的真正价值在于独特的技能(比如认知方式), 和独特的技能所造成的结果.
一旦这个独特的技能变成可复制的经验, 哪怕Martin说的你一句也不知道, 大家共同的词汇你一个也没记住(显然这种极端情况也不可能出现), 这时候你反过去在去看其它具有独特技能的家伙们给出的经验,结合/反对/补充之, 你不是大师也能成一个大嘴了...
在偷得浮生半日闲的回复。
大家在讨论这些阳春白雪的时候, 我觉得首先应该关注一下自身的时间分配, 别人的认识会在一定程度上增加你的技能, 但这种投资并不是最有效的(当然保险系数稍高), 编程人员的真正价值在于独特的技能(比如认知方式), 和独特的技能所造成的结果.
一旦这个独特的技能变成可复制的经验, 哪怕Martin说的你一句也不知道, 大家共同的词汇你一个也没记住(显然这种极端情况也不可能出现), 这时候你反过去在去看其它具有独特技能的家伙们给出的经验,结合/反对/补充之, 你不是大师也能成一个大嘴了...
# re: 域模型向左走(充血)，向右走(贫血)
2007-09-13 23:11 | 怪怪
@daizhj
"这里的类有的甚至连方法和属性都还没有，甚至只是一个空壳"
"然后当模型完事之后，再从用户角度出发使用用例去构建用户场景，在这个阶段还可以发现一些类，但要注意的是用例的分解粒度（避免出现分析瘫痪），再后才是时序图，协作图的交互建模（对象关系及行为事件等）以及模式和类属性填充,需求复核等"
说实话我以前确实误解你了(我以为你还没有开始走上设计之路), 你知道的比我想象中多的多. 这是我犯了一个我自己总是提醒我自己和其它人的错误: 不要对你发言对象的水平做任何假设... 不过我是看了你们Discuz!NT的代码才... :P 看到今天的讨论, 就知道其实你能理解我上次给你那一大篇的意思所在. 不过你也说了, 不合适讨论的问题就放一边吧..
你说的这套方法, 还有亚历山大同志兄弟说的, 其实是一套方法. 我觉得咱们可以放下脸面, 互相承认别人知道的东西咱们还没有读到或者读的不够细. 比如我, 这套方法我以前也大致看过, 也实践过, 不过因为工作性质和思考的方向变了的原因, 还有原来学的就不到位, 说实在的我已经忘的差不多了.
但是我比较庆幸我没有真正去掌握它, 因为它的内容也很多, 真想掌握好得花很多年的时间, 而且我现在已经开始质疑这套方法的适用性了(至少在一定的领域内). 按照我的看法, 类根本不是在任何阶段发现的, 因为类最终的设计必然是在综合权衡之后妥协的结果而不是一下子就能定出来的.
某某说过, 任何伟大的框架之中都充斥着大量的妥协, 就是这个道理. 如果在自顶而下的设计过程中, 按照这套方法, 过早的得到类这个概念的层次, 虽然"无限接近现实世界",要么是别扭的要死, 要么最终面目全非. 这就是为什么到今天, 还有无数重量级的元老级大师质疑OOA/OOD提高软件生产效率, 同时产生了一大堆类似于极限编程的毛头小子反对事先设计的原因.
为什么呢? 因为在开始阶段, 大量的场景和用例让你对后来的过程根本没有时间去详细思考, 而后面的过程还往往要承担在开始阶段根本搞不清楚的隐性需求和限制. 也许面向组件的编程真的是一次跨越吧, 因为使用的技术(包括接口这种契约等概念性的技术)虽然没有变化, 但在方法论上可以说完全不同了(不过有很多骑墙派认为是一脉相承).. 不过越新的理念和方法, 就越抽象, 讨论起来就越不像在说编程技术, 而且这个是另一个话题了.
干自己的活去了, 有空再继续 :).
"这里的类有的甚至连方法和属性都还没有，甚至只是一个空壳"
"然后当模型完事之后，再从用户角度出发使用用例去构建用户场景，在这个阶段还可以发现一些类，但要注意的是用例的分解粒度（避免出现分析瘫痪），再后才是时序图，协作图的交互建模（对象关系及行为事件等）以及模式和类属性填充,需求复核等"
说实话我以前确实误解你了(我以为你还没有开始走上设计之路), 你知道的比我想象中多的多. 这是我犯了一个我自己总是提醒我自己和其它人的错误: 不要对你发言对象的水平做任何假设... 不过我是看了你们Discuz!NT的代码才... :P 看到今天的讨论, 就知道其实你能理解我上次给你那一大篇的意思所在. 不过你也说了, 不合适讨论的问题就放一边吧..
你说的这套方法, 还有亚历山大同志兄弟说的, 其实是一套方法. 我觉得咱们可以放下脸面, 互相承认别人知道的东西咱们还没有读到或者读的不够细. 比如我, 这套方法我以前也大致看过, 也实践过, 不过因为工作性质和思考的方向变了的原因, 还有原来学的就不到位, 说实在的我已经忘的差不多了.
但是我比较庆幸我没有真正去掌握它, 因为它的内容也很多, 真想掌握好得花很多年的时间, 而且我现在已经开始质疑这套方法的适用性了(至少在一定的领域内). 按照我的看法, 类根本不是在任何阶段发现的, 因为类最终的设计必然是在综合权衡之后妥协的结果而不是一下子就能定出来的.
某某说过, 任何伟大的框架之中都充斥着大量的妥协, 就是这个道理. 如果在自顶而下的设计过程中, 按照这套方法, 过早的得到类这个概念的层次, 虽然"无限接近现实世界",要么是别扭的要死, 要么最终面目全非. 这就是为什么到今天, 还有无数重量级的元老级大师质疑OOA/OOD提高软件生产效率, 同时产生了一大堆类似于极限编程的毛头小子反对事先设计的原因.
为什么呢? 因为在开始阶段, 大量的场景和用例让你对后来的过程根本没有时间去详细思考, 而后面的过程还往往要承担在开始阶段根本搞不清楚的隐性需求和限制. 也许面向组件的编程真的是一次跨越吧, 因为使用的技术(包括接口这种契约等概念性的技术)虽然没有变化, 但在方法论上可以说完全不同了(不过有很多骑墙派认为是一脉相承).. 不过越新的理念和方法, 就越抽象, 讨论起来就越不像在说编程技术, 而且这个是另一个话题了.
干自己的活去了, 有空再继续 :).
# re: 域模型向左走(充血)，向右走(贫血)
2007-09-13 23:25 | 怪怪
=============================================
关于这两个问题, 我回答一下吧~
1.还是那句老话,事是干出来的,不是说出来的.
你说的对, 问题是你干的东西, 我也只看见Discuz!NT啊.., 未来我会有自己的一个东西拿出来, 足够完善了就会开源, 到时候你在帮我挑刺吧, 现在呢处于敏感阶段, 但你总不能认为我多说两句就不干事吧, 毕竟我也得吃饭 :).
2. 最后说一句,有互相指责(而不是讨论)的时间还不如抽空提高一下自己代码质量或修改BUG来的实惠:)
前半句回答过了, 指责只是一种手段, 因为我呢不会为人处世, 能当个苏格拉底的"牛蝇"就是我的目标了, 反正你也不能拿毒药毒死我 :), 只希望提个醒, 如何反映就是你的事了, 既然我不会为人处事, 那么我就这么干了, 你能接受我的风格呢, 也许未来就成了朋友, 否则呢就会保持一定距离. 这正是我交朋友的方法啊.., 可惜还没怎么成功过 :)
后半句你说的太对了, 我确实不如去干自己的活, 分享心得(无论是好话赖话)对我来说显然带来的好处不如我损失的时间; 所以呢我恬不知耻的说一句, 既然我写了好几百字上千字(骂人的人恐怕没这耐心吧), 你是否不要简单的理解为我在发泄呢? :)
既然上了网, 大家都带了面具, 不妨肆无忌弹一点, 只要不是无聊的重复性质的脏话, 就别在乎那么多了, 你说呢? 当然你要说你这儿不欢迎我, 那我滚蛋就是了 :P
1.还是那句老话,事是干出来的,不是说出来的.
你说的对, 问题是你干的东西, 我也只看见Discuz!NT啊.., 未来我会有自己的一个东西拿出来, 足够完善了就会开源, 到时候你在帮我挑刺吧, 现在呢处于敏感阶段, 但你总不能认为我多说两句就不干事吧, 毕竟我也得吃饭 :).
2. 最后说一句,有互相指责(而不是讨论)的时间还不如抽空提高一下自己代码质量或修改BUG来的实惠:)
前半句回答过了, 指责只是一种手段, 因为我呢不会为人处世, 能当个苏格拉底的"牛蝇"就是我的目标了, 反正你也不能拿毒药毒死我 :), 只希望提个醒, 如何反映就是你的事了, 既然我不会为人处事, 那么我就这么干了, 你能接受我的风格呢, 也许未来就成了朋友, 否则呢就会保持一定距离. 这正是我交朋友的方法啊.., 可惜还没怎么成功过 :)
后半句你说的太对了, 我确实不如去干自己的活, 分享心得(无论是好话赖话)对我来说显然带来的好处不如我损失的时间; 所以呢我恬不知耻的说一句, 既然我写了好几百字上千字(骂人的人恐怕没这耐心吧), 你是否不要简单的理解为我在发泄呢? :)
既然上了网, 大家都带了面具, 不妨肆无忌弹一点, 只要不是无聊的重复性质的脏话, 就别在乎那么多了, 你说呢? 当然你要说你这儿不欢迎我, 那我滚蛋就是了 :P
在偷得浮生半日闲的回复。
浙公网安备 33010602011771号