语言相关的OOD

很多人觉得OO只是跟需求有关系。
但是我觉得OO一定跟实现是相关的。同样是易变的需求,一行就实现跟两千行实现设计起来肯定是不同的。
既然OOD跟实现相关,所以我觉得一定也和语言相关。
我的经验是如果你写C或是java代码,函数就可以写的短些(代码行数),类可以设计的小些。C++的话由于函数定义修改不方便(两个文件),所以C++的设计我一般让类大些,函数相应的长些。

OO对语言平台当然有选择要求,但是我们尽量摆脱OOD对语言平台的依赖,所以,有设计模式,设计模式可以用UML Java .NET等不同OO语言工具同等表达,这说明OOD的奇妙处。

贯穿OOA和OOD的是领域建模,可以将需求分析到实现一下打通。
[该贴被banq于2009-05-24 09:59修改过]

OOP,那肯定是与语言相关的。
OOD,应该是尽可能与语言无关。
如果觉得你的OOD是与语言相关的,那可能你是一步到位在直接做OOP了。
我理解,
1)在OOD阶段,主要是根据需求,做对象集的设计。我需要设计多少个对象?这些对象之间的联系如何?
2)在OOP阶段,才需要关心所选语言的特征。譬如,我在OOD里有多重继承,而在OOP里选的是Java,就得置换成接口。

同意beepbug的观点。不管用Java,C还是一些别的OO语言,虽然实现方法不同,但是基本OO功能都可以支持。因此设计的时候可以抛开具体语言细节,更关注对象。

关于OOD与OOP的关系,这个问题确实让我很困惑。
Martin Fowler的重构理论就没有分开他们。

而且我发现,其实决定用什么方式是跟人的性格有关的。

有的人喜欢条例分明,但是有的人喜欢快速有效。
喜欢条例分明的人喜欢把OOD和OOP分开,但是喜欢效率的人则希望马上完成工作,又快又好。

所以,我现在的问题就是,既然性格不同,那我们该基于什么原则讨论呢,这个问题一直是我觉得麻烦的地方。

简单的工作当然可以快速有效,复杂的系统开发还是要按流程进行,毕竟不是每个人都可以凭大脑记住一切,一眼看到最好方案。不做设计计划,盲目开工,只会在不断返工中浪费时间。

所谓磨刀不误砍柴工。

我最喜欢的开发模式是这样的,
有需求分析,但是没有需求文档。
业务人员随叫随到。

有模糊模块划分,但是没有最初设计。
项目经理跟踪并不断修改项目设计。

其他的问题依靠开发人员良好的协作解决。

而且我认为,良好的协作比公共接口定义有效的多。