回复关系：
作者 内容
 j2ee   造句作业

造句作业(选自Dr.OO语录)



摘要









第一部分

　






学术民主--学术民主赋予每个人发表观点的权利，但是关键不在于观点，而在于说出观点的方式



学术文章--因为作者的很多用词是极不规范的，也不可能出现在正式的学术文章里头



学术进步--“带坏风气”的意思，如果以后大家都可以不遵守规则、没有根据地乱下结论，以偏盖全，偷梁换柱，那将是学术进步的悲哀。 



（学术）腐败--科学界出现王朔现象，也是一种腐败



学术态度--该文暴露出学术态度和文风的问题



做学问--这关系到做学问的问题，以免给学生和新手造成不好的影响



科班--我猜你可能不熟悉OO，或者不是软件科班的



错误的写法--文章不严谨、错误的写法会被一些人仿效



心理反应--我想很多OO的爱好者，都有与我类似的心理反应



后怕--《程序员》居然刊出这样的文章，令人遗憾而后怕！ 



误导--毕竟错误的观点（尤其是看问题的方法）在市场、通讯不成熟的情况下会得到局部放大，造成大面积的误导。



不学无书--不学无书，只好拿民主做遮羞布，实际上却干这着破坏民主的勾当！） 




第二部分






妖魔化--喜欢无中生有，达到自己妖魔化Dr.OO的目的，可谓不择手段



造反--但是百家争鸣不等于抱着造反的态度乱鸣乱放



乱鸣乱放--（见上）



暗流--好象出现了一股“反UML”的暗流，



阵地--所以，要争取宣传阵地——媒体！ 



话语权--话语权太重要了，错误的东西说了1000遍，就有可能变成“伪真理”，如果听不到正确的声音。



无数--是因为有无数的专家、用户和程序员通过自己的实践证明了UML的生命力，



陈腐--过了1年之后（...）居然又把陈腐的观点抛出来，我不知道有何用意。



定论--我不屑也没有必要反驳作者对UML的错误论点，因为这早有定论



嘴脸--一副煽动者的嘴脸，卑鄙无耻！



下岗--你神经病犯了？是不是又下岗了? 



谣言惑众--一副“四人帮”走狗的嘴脸，善于谣言惑众：



红眼病--不然不会对我这么感兴趣，也许下岗了，整天不务正业，要么得了红眼病



见不得人--不要躲在阴暗处，说一些风凉话，做一些见不得人的勾当。



长大--我是看着umlchina长大的


　


点评




致谢

　







本文版权为作者所有，原句为原句的作者所有，未经授权不许摘抄
 02/05/24 20:15 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  唉，这样的说话方式有人看不惯当然是很正常的。
 02/05/24 20:31 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  尤其作为一个UML的前辈和本组的名誉组长，唉！
 02/05/24 20:50 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  但我看不出来Dr.OO象作过项目的样子
很奇怪他的自信从何而来。自己没有经验的话。
他的培训和咨询如果也是这样。。。。，好像恐怖了一点。
原来还以为他是学生。
 02/05/24 20:58 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee   我觉得主要是说话的方式需要注意
至于做没做过项目就是他的老板，他的客户和他的学生需要注意了解得了。
 02/05/24 21:02 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  福楼拜对愚昧的认识：
“现代化的愚蠢并不是无知，而是对各种思潮生吞活剥。”

我是从那本著名的“生命中不能承受之轻”的著名的序言“人们一思索，上帝就发笑”中看到的。真是真知灼见。
 02/05/24 21:20 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee   高见！？
 02/05/24 21:27 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 umlchina  Dr.OO的水平问题：Dr.OO是UMLChina老网友，我也见过Dr.OO，而且一起吃过饭。
我认为：拿我作比较，Dr.OO对OOAD/UML/UP的认识比我要深刻得多。

连我都有信心提供UMLChina培训，目前定位为以下两种开发团队和个人：
1. 已经有一些UML知识，想在下一个项目使用UML进行开发，但不知道怎样做。
2. 已经在一个或两个项目中使用UML进行开发，但充满了疑问。

3. 不需要UMLChina培训的团队：已经在统一过程和UML方面积累了丰富的经验，有很好的mentor，人员也得到了很好的培训。

我相信：Dr.OO还能为第3种团队提供培训。

以上纯属个人认识。

另：Dr.OO并非博士之意，这和RationalEdge杂志里的Dr. Use Case是类似的，但好像Dr.OO比他还早。
 02/05/24 21:59 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  但愿一切如斑竹所说，我也愿意向他学习
 02/05/24 22:02 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  劝一劝Dr.OO,不要卷起UML的大旗打人
 02/05/24 22:05 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 umlchina  你好！Dr.OO自有其风格，我不认为有什么问题。
 02/05/24 22:07 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  那真是大大失敬了。frankwoo的问题我也想知道答案，能指教一二吗？
记得frankwoo曾有个问题是
分部的多层结构如何用顺序图表示，
还有一个问题是
UML怎样体现系统的实际体系结构（除了单纯的class图以外），特别是怎样表示出来该体系结构下的系统的交互。进而对应到详细设计，实现任务的分配。

这两个问题我都不懂，在顺序图中将分部类用一个箭头指向自身，简单注明循环在我看来对实现上的帮助和废话无异。以我的能力，以为从这个自身关联的类做出详细设计图的代价比实现编程还大，每个类，每个成员函数，我想当时frankwoo先生所说的图会太大应该是指整个图的规模，而不是某一张顺序图吧。

不知哪位组长大人有以教我？

嗯，我再略微细化一下问题，设一企业有层次结构，但各分部下部门层次和部门数都不定，于是设计一个自己关联的组织类表达这一概念。组织内的员工有共通的职责范围，在其下的分组织内可能有进一步的细化或扩展，现在给定某个具体员工，要获得其人的职责一览，势必要从他的直属组织到最上层组织进行一次遍历，对职责的冲突以下层优先。询问：顺序图，详细设计的实现图等该如何表示为宜？以达到生成大家津津乐道的仅仅有编程基础知识的程序蓝领都能基本正确编程的详细设计书（图）为目标。

先谢谢组长的指教了。
 02/05/24 23:05 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 anti-dr.oo   有耐心，有毅力
更有水准，有眼光
 02/05/25 02:31 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  umlchina有必要替别人的水平做担保吗？
:我认为：拿我作比较，Dr.OO对OOAD/UML/UP的认识比我要深刻得多。
这句话我只能理解为您老的谦逊。您老坚持不删贴的英明我就不重复表扬了。

:...
接下来的内容类似于广告。

:另：Dr.OO并非博士之意，这和RationalEdge杂志里的Dr. Use Case是类似的，但好像Dr.OO比他还早。
您的意思是不是说他并没有真正获得过博士学位？

实际上killcamel兄的意思是问有没有实际项目经验。如果光是会背书唬唬没读过书的小朋友还可以，实际没太大用。纸上得来终觉浅啊。马谡就是这样一个典型，连诸葛亮都看走眼。
 02/05/25 09:09 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 Dr.OO   我的Dr.OO其实很早以前仿效MSDN的Dr. GUI, 我很欣赏他, 我努力向他学习幽默, 不过可能我没有学好, 所以我还是忍不住会骂国内外的垃圾.
 02/05/25 09:20 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 idlecrook   回复: 那真是大大失敬了。frankwoo的问题我也想知道答案，能指教一二吗？
:)不知道是否理解了你的意思，你是不是想说一个比较深的类似继承的问题？顺序图不是描述类之间关系的，是描述对象（类的实例——一个具体员工：））的。所以顺序图不可能抽象到类层次上来，只能描述几个具体实例的场景。所以你的问题用时序图来描述是不合适的。你的这个问题用类图最好了，当然了你没有必要用继承，你可以用powertype(把职务抽象成类)，这样可能更便于处理：）
 02/05/25 09:58 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 idlecrook   回复: 福楼拜对愚昧的认识：
一个人看到一个新鲜的大梨，来个囫囵吞梨（要是“生吞活剥”的方式不当），被噎着了，就说这是梨三大硬伤呀！
 02/05/25 10:30 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  有道理啊
所以不该骂梨，应该直接骂吃梨的人
 02/05/25 10:32 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 ray_czh   回复: 我的Dr.OO其实很早以前仿效MSDN的Dr. GUI, 我很欣赏他, 我努力向他学习幽默, 不过可能我没有学好, 所以我还是忍不住会骂国内外的垃圾.
Dr. 看来不是doctor 而是 director 。
 02/05/25 10:37 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  类图中是只要把组织类画出一个自我关联就可以了
职责的确是应该做成一个类，但我现在是想知道从末端组织获得所拥有的职责一览这一步骤的顺序图和详细设计。
分部和其下的组织不是继承关系，都是同一个组织类，应该类似设计模式的组合模式。
照我的理解，顺序图是描述类的实例（对象）之间的消息关系，实际是表示了某一步骤中的处理顺序。现在暂且不考虑职责类，类只有一个组织类，实例有从末端组织到最上层组织的不定数，在一般的顺序图中不可能反映更详细的处理，只能是一个自上向下，得到职责之类的方法箭头，边上注明循环。对职责的合并，冲突的下层优先等详细处理的表示恐怕困难。
说白了，加上职责类，类图中也不过是组织类和职责类，对于一些程序员，是足够了，但frankwoo是要为了任务分配做详细设计，对得到职责这一方法无疑需要更详细的表示。
我前面不说职责类，是不打算复杂化，这只是我举的例子。最终目的是知道象组织这样的类，在处理中的迭代如何用顺序图表示，从类图得到详细设计的代价会不会比编程实现更大。至于这一迭代是为了得到职责，还是别的，其实并不重要。
所以我问的是，给定一个末端组织，得到职责一览这一方法的顺序图和详细设计，窃以为是应该用顺序图来表示的。
当然，我的类图是在组织结构方面只有一个组织类，如果认为每一个部门都应该有自己的类，或者每一层部门都有一个部门层次类，那就是另一个问题了。
 02/05/25 10:44 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 idlecrook   回复: 类图中是只要把组织类画出一个自我关联就可以了
我觉得这好像牵扯到算法问题了。如果你要遍历某一棵树，应该用递归来实现。UML不是算法描述语言。不知道我理解的对不对？
 02/05/25 10:56 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  2、“UML下不着地——无法提供直接到位的素材指导程序员编程”，错！
UML脚踏实地——可以有效地帮助、指导程序员编写和提高代码质量
------------------------------------------------
以上见Dr.OO的UML天地合一贴子

其实我真正感兴趣的是详细设计图，个人觉得从类图转换到详细设计的代价比编程实现还大，这多半是我还没学好UML，所以请教这一问题。
我对脚踏实地最感兴趣，但仅仅类图要达到有效地帮助、指导程序员编写和提高代码质量 恐怕还不够。所以请高手赐教详细设计的方法。
 02/05/25 11:06 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 idlecrook   回复: 2、“UML下不着地——无法提供直接到位的素材指导程序员编程”，错！
大哥，我很笨。这种递归算法怎么用UML表述我真的不知道。链表操作我倒是见过一个
 02/05/25 11:09 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  我也不知道。我不是要考人，是的确要学习。
好奇，就你所看到的，
链表操作的UML表述你觉得和实际编程时的指针操作哪一个看起来更简单？
之所以点名组长们回答，是因为这一组织上的问题我想还不会过于少见，高手肯定知道解决方案。UML在类图中提供了自我关联的组合形式，那么在顺序图中肯定应该有对应迭代的方法，只是我不知道而已。

参见下文，同样来自Dr.OO的UML天地合一贴子
-----------------------------------
3、“UML一盘散沙——没有在细微之处建立建模图形之间的联系”，错！
UML和谐统一——从不同视点全面、细致地反映了业务和系统
 02/05/25 11:21 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   组织与职责之间根本没有直接的关系，一个组织可以对应多个职责，一个职责可以对应多个组织。必须引入中间的“职员”类把组织和职责一一配对。职员是组织的部分，同时也是职责的部分。
 02/05/25 11:23 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 idlecrook  回复: 我也不知道。我不是要考人，是的确要学习。
你理解错了，时序图描述的是场景，不会有迭代，也不会有递归。你还是没有从对象的角度理解时序图。我觉得UML描述的链表挺容易理解的，但不是用时序图。用类图，和状态图描述比较好
 02/05/25 11:29 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   如果一个组织只允许有一个职员，一个职员只允许对应一个组织，那我们可以将职员归并到组织中变成它的属性。否则就应当分开成不同的类。你将需要多个类表示的一个问题硬要省略为一个类，然后说“他表示不清楚呀”！
 02/05/25 11:31 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  我举的例子可能不是很恰当
我只是想用这个简化的例子学习如何在详细设计中描述迭代操作。
取得职责只是一个例子，任何一个别的例子都可以。
如果真要细化这个组织方面的设计，还有诸如一个职员能否同时在两个组织内兼职，是否纪录任职历史等问题。
另外，我的组织职责的意思是财务部可以检查账目，其下出纳科可以支出现金等，个人以为是职责和组织相关，不是和具体某个职员，当然有可能某个职员的能被破格赋于超越所在组织的职责范围，但我不打算如此细化问题。
如果不满意，比如得到组织自上而下的全称也可以，好像财务部出纳科第一组，当然将此可以设计在组织类中作为成员变量，但我只是想知道迭代操作的描述。
 02/05/25 11:40 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   因为组织是个归纳结构，那么即使最底层的组织只对应一个职责，比较高层的组织也会对应多个职责。所以必须将组织和职责分开，中间引入一个类把他们关联起来。至于这个类叫什么，可以叫做“组织与职责的一个对应的关系”吧。一个组织可以引出多个这个对应关系，一个职责也可引?br>
 02/05/25 11:46 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  我的目的不在组织和职责关系，而是迭代的描述
 02/05/25 11:50 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  可能是我理解错了
既然有人对我举职责这个例子不满，我就换一个吧。
设一企业有财务部，销售部。财务部下设会计科，出纳科。销售部下设国内总部，海外总部。国内总部下有上海中心，广州中心，北京中心。海外总部下设美国部，欧洲部，日本部。
如果要获得组织全称，当然可以画出得到会计科全称的场景，得到欧洲部全称的场景等等。不过我个人以为这时归并成用一个得到组织全称的场景描述的顺序图更好。
就这个例子而言，是可以在组织内直接增加一个全称的成员对象来解决。但如果要得到诸如某一组织的员工人数占上级组织的总人数比例，统计销售部下属组织的销售额占上级组织或全公司销售额的比例等数据时有可能直接增加成员变量来解决吗？不以这些为例，是因为牵涉了别的类在内，免得像职责这个例子一样，被类之间的关系设计隐藏了表示迭代关系这一最终目的。
 02/05/25 12:08 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sanjoe  回复: 可能是我理解错了
这样简单地建立组织的框架好像不是很恰当。把各种组织简化成一个类可以看作是一种设计方式方式，但是可能难以表达各种对象的属性和功能以及组织内部的构成关系。
比如在组织结构中，销售部门包括了国内总部，欧洲部，法国部，虽然都是销售部门，但除了在销售这大的概念上相似以外，在很多其他的职责方面不太可能是一样的（这方面就需要去专门了解组织结构的职责了，不是我们讨论的范畴了），所以也许利用类的继承或者聚合关系更恰当。也就是欧洲各个国家的分部都是欧洲分部的组成部分。整个销售的组织结构可以类似简历。
killcamel的意思可能是部门的层次可能是不能预知的（尽管一般情况下对一个固定的组织很少出现），就好像文件夹，可能动态的有很多层。这样其实是大大简化了组织结构的问题，也就是很多组织结构的细节不再考虑，而仅仅是为了研究这个计算。这个时候组织就退化成一个文件夹问题了。这应该是一个叠代计算，就是二插树的搜索，这个时候应该利用活动图更好些，而不是序列图，因为这是一个算法流程问题，而不是类之间的关系问题。不知道是不是这样？
 02/05/25 14:32 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 opensky  回复: 那真是大大失敬了。frankwoo的问题我也想知道答案，能指教一二吗？
see
http://www.smiling.com.cn/group/posts/view_forum.ecgi?group_id=12879&res_message_id=1100537

please
 02/05/25 17:02 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  呵呵，的确只是一个算法流程问题，我对活动图不熟
多谢指教了。
呵呵，我如果早把它退化成一个文件夹问题，也许就不用这么多解释了。
选择这个组织，只是因为高文的例子中举了关于组织方面的问题。我觉得高先生的全程建模方法在这个例子中固然简单，但一旦组织结构发生变化，好像就要重新建模，感觉不如UML的类图中自己关联方便。但UML的详细设计应该如何，就不知道了。正好frankwoo的分部是多层也是组织方面的问题。所以我假设了这个组织问题。
您说“killcamel的意思可能是部门的层次可能是不能预知的（尽管一般情况下对一个固定的组织很少出现）”，的确和我本意比较接近。一个固定的组织在一个固定的时刻肯定有确定的部门层次，只是一方面为了在不同企业间复用程序，另一方面企业的部门重组也不是很少见的，为了程序的灵活性，我不在程序的类设计中决定部门层次结构，只是在我的组织类cOrganize中设计一个储存cOrganize指针的list作为下属部门的链接，用一个初始化函数决定部门关系。否则感觉就和高先生的全程建模方法类似，不够灵活了。
但部门之间的确职责方面不可能是一样，所以我最初的问题就是获得职责一览。我的考虑是设计一个事件处理虚基类iProcessBase，所有的处理如展开市场活动，统计销售数据，检查账目，现金支付等操作均为iProcessBase的子类。另外有一个职责基类cAuthorityBase，构造函数是protected，对所有的iProcessBase子类均有一个以该iProcessBase子类指针为参数的虚Process空函数。在诸如允许检查账目，允许折扣等cAuthorityBase的子类（也就是具体职责类）中对可以处理的事件类重载该具体事件类的Process函数。
雇员对象（cEmployee）从其所在部门获得职责一览，也就是一个储存cAuthorityBase指针的list，进行某项工作时只是简单的将这一处理的具体类（iProcessBase的子类）作为参数，传递给雇员对象的cAuthorityBase指针list中每一项的Process函数，直到被执行或cAuthorityBase指针list遍历完毕。换句话说，在我的设计中一个销售部成员企图检查财务部数据失败不是由于他不是财务部成员就直接退出函数，仅仅因为他从部门获得的职责一览中对检查财务部数据这一iProcessBase子类的Process函数全部失败而已。只要向他个人追加这一职责，他就可以在销售部检查财务部数据了。
这只是我简单的设想而已，我对牵涉到组织结构的ERP也不熟，这方面没什么经验，肯定有许多不妥之处，比如销售人员的地域限制该如何考虑等等。这一构思若要真正实现，关键是事件处理虚基类iProcessBase的所有子类必须相对稳定，并且没有遗漏。我也相信在设计模式的讨论组中一定有更好的解决方案。之所以以前没有详细解释，不过是不想让这些类之间的关系影响主要问题，就是这个迭代的算法流程描述。
其实是我觉得单纯就这个叠代计算来说，编程上的实现很简单，但要画出详细设计图（书）的话，代价（耗费的时间，精力）可能比具体编程实现更大，想知道有没有什么简单的方法。也许要达到供蓝领程序员用的详细设计书注定要有如此巨大的代价。
呵呵，看了非程序员说UML2.0对活动图有很大的改变，学UML时对活动图就只稍微看了看，基本上跳过了，看来人是不能耍小聪明啊。多谢赐教了。
 02/05/25 20:41 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 风雪漫天  各位也都是高手，干吗喜欢纠着别人小辫搞这些无聊的事呢。不解
 02/05/27 08:56 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  高手看见国内外的垃圾，还是忍不住要骂的。
但是骂垃圾的不一定就是高手，不骂垃圾的也不一定就是低手。

如果垃圾实在是太垃圾，高手也不会骂的。比较具有欺骗性的垃圾，高手会跳出来骂一骂。就象太FAQ的问题，高手也是不回答的一样。
 02/05/27 09:48 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 ec05   回复: 那真是大大失敬了。frankwoo的问题我也想知道答案，能指教一二吗？
我也说两句..

本身这个问题,在实际工作中就遇到了(很普遍),我是用Composite去做的..

至于怎样让程序员理解,我觉得这与team的平均水平有关,好的话,一个模式的描述,就明白了.

问题本身还涉及Data persistent,就是如何映射成关系数据库中,又满足查询的效率要求.

说到什么"硬伤",每人都有自己的想法,甚至是商业的考虑(比花巨资做广告效果好多了),这很正常.

国内的优秀技术人员,不比国外,生存压力大(没有可能做到自己想做的事情),这才是国外比国内技术先进的主要原因.
如果有天他们都可以不考虑生存,去搞研究了,国内就有希望了.
 02/05/27 11:45 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  主要是为了umlchina中有一个比较好的说话的氛围，大家互相讨论，而不是高人一等的“定论”和谩骂
不是吗？
 02/05/27 13:13 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 风雪漫天  这是对的，但是也没有必要把他轰走才甘心。
 02/05/27 13:14 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  有吗？
 02/05/27 13:22 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel   的确是Composite，只是简单例子不想讨论职员是否设计成leaf的问题
的确，对有经验的程序员，一句话就足够了。
对一般合格的OO程序员，给出个类图也就可以了。
具体实现的好坏就完全看程序员的水平了。
但team内未必都是好的程序员啊，给没有经验的分配这种编程任务，写详细设计还不如就自己直接完成算了，但项目规模只要稍微大一点，恐怕就不可行了。不写详细设计的话，就鬼知道变成什么结果了。
我不过是蓝领程序员，不用操心这问题，但各位老大遇上这种问题是怎么解决的呢？好奇中。。。
 02/05/27 18:23 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel   呵呵，这都怪sealw不好
博士刚上任就给人来个离休干部待遇。结果真的要离休了。
可怜umlchina，关云长至少还斩了颜良，诛了文丑，Dr.OO区区一个高展还未解决就壮志未酬了。
不过也没有人要把他轰走吧。不过就是知道了理论上可以，想知道实际上如何应用也不为过吧，因为这个理论和不少人的实践经验好像还有点差距罢了。想根据实际现象展开一些讨论。
个人想法不同，博士要认为这些讨论实际问题的愿望是一些丑陋, 阴险"程序员"的恶劣行径。那么我想谁都没有办法。至少就我来说，也就只有丑陋, 阴险一回了。不过还是振臂高呼一声，打倒sealw。也算替人出出气。呵呵。
 02/05/27 18:45 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 pigprince  这里是自由的论坛，又不是在玩老鹰捉小鸡，谁能敢走谁啊？
这句才是问题的实质：“个人想法不同，博士要认为这些讨论实
际问题的愿望是一些丑陋, 阴险"程序员"的恶劣行径。那么我想
谁都没有办法。”

呵呵，说又说不过，就躲了，这样的态度有点意思，有点意思啊！
 02/05/27 18:56 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  你，你，你有够丑陋，够阴险！呵呵。
 02/05/27 20:18 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  有道理，大家都是在规则允许的范围内玩。要是那天规则改了，说不定大家就不玩了。
 02/05/27 20:26 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  大家都是成年人啊
 02/05/27 21:09 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：