关于OO

09-05-16 tearoffhu
最近Kiss比较火,虽然我基本认同他们的想法,但是写了这么多年的OO还是放不下。尤其是在应用程序的开发上,我觉得OO还是比较有用的。

我一般是一到两个人开发一个程序。所以设计上没有考虑过多人合作的情况。所以我对不同技术水平人员合作的情况经验太少。说道应用程序我喜欢需求驱动开发,所以我倾向于在设计之前,尽可能的做需求分析。需求然后是设计。设计基于需求分析的结果。

在OO方面我一般只注意需求的易变性,部署情况和重用三方面。在设计上需求易变的部分做隔离,分开部署的做借口分离和包设计,重用基本上是给维护用的。

我现在对OO的总结基本上就是上面这些。至于基于概念设计对象,我本人持否定态度,我本人认为一切都应该基于需求,很多想当然的概念在需求中实际上是另外的情况。

现阶段我的OO想法就是上面这些,希望有人能和我讨论,谢谢。

tearoffhu
2009-05-17 07:13
为什么没人回复呢

tearoffhu
2009-05-17 13:38
没人回复。我具体写下我用的方法吧。

重点还是需求,我一般注意下面几方面:

一、需求中不确定的部分:很多时候应用工程师给出的需求有些是在现阶段没办法确定的,但是由于要出产品,随便加上去一些功能点,这些功能点在文档是不明确说明的。这些东西需要我们开发人员注意,设计的时候做好隔离,准备将来重写。

二、应用工程师的惯例:任何公司做产品的时候都会有些惯例,重用以前的实现方法。一般这部分是很稳定的,设计的时候,可以认为这部分是不会改变的,放心重用。当然也有例外,比如新人加入的情况。这样的情况,就看我们的灵活处理了。

三、需求改进的方向:这部分是由项目目标决定的,项目都是有目标的,项目的目标也是项目后续阶段开发的中心。理解这点以后,设计的时候要对与项目目标关系较大的部分和关系不大的部分分开处理。

四、配置部分:一般情况下产品的配置都是需要特别处理的,这部分要根据不同的需求不同考虑,最好考虑使用反射。

上面这些是于需求需要注意的部分,大都是文档里不提到的部分,很多需要和应用工程师反复讨论才能确定。关于需求文档说明的部分。敏捷开发和KISS我都比较推荐,其实我觉得这部分我们是可以随便做的,只要自己觉得好维护,就没有什么问题。

关于QA,QA测试是有方法,我也知道一些,但是现阶段我还没有办法针对QA做设计。

希望各位大虾多提意见,我在这里热烈欢迎。

谢谢

tearoffhu
2009-05-18 16:31
没人回复呢?

为啥呀?

说两句呀,交流交流。

banq
2009-05-18 18:17
我的经验是:四色原型+DDD 足够对付如今需求领域的一切。

敏捷XP大多数是围绕DDD模型。

ACoder
2009-05-18 21:53
其实很多时候文档是不能完全描述业务的,包括四色原型,一个开发人员很难通过一个四色原型就学会业务,从而了解整个业务的全貌的,其实很多时候对于一个开发人员而言,代码是最好的老师,往往一些业务中特别强调或者有特殊处理的时候,大部分是通过口口相授并参照代码进行了解的。

对于稳定的模块,尽量或者最好不要去动,让其保持优良的运行状态,然后将精力放在那些无法确定的事情上面。对于无法确定的事情,应用注释+文档的方式进行标注,或者加入一些Interface来标识可能会有存在一些行为或存在行为的对象。

开发的模式主要看你们公司采用什么样子的模式,这个一般公司都应该有规定,而且也要根据人员的多少来确定。不过那种方式要做到需求驱动开发,测试驱动开发。这是最重要的。

tearoffhu
2009-05-19 14:47
刚才看了一下四色原型的文章,

我以前对四色一点也不了解,大部分时间都看需求过程了。

我对四色了解的不多,但是基于我对需求过程的了解,我还是想提出我的问题。

需求过程提出:你对用户工作了解到的知识离系统越远,你的需求才能越有效。

所以我理解的需求随着业务员认识的深入,随着用户的反馈,需求会不断的改变。也就是说需求的个动态的过程。

四色虽然看起来可以描述需求,但是它描述的需求是静态的。

没有说明需求会朝着哪个方向变化。

而我觉得业务员实际上是可以估计出需求变化的方向的。

比如,业务员对工作了解的模棱两可的地方,或者用户经常使用的部分都是需求容易发上变化的部分。

需求的变化对设计又很有影响(这部分我就不多说了)。

我对四色了解的不多,希望有四色经验的人能好好讨论一下。

我的观点是 设计人员应该兼职业务员,参加业务员的会议。

能看懂业务员的文档,这样才能做好设计。

tearoffhu
2009-05-19 16:21
我刚才看了一下DDD的有关知识。

我的主要问题在领域层.

它说

领域层:负责表示业务概念、业务状态的信息和业务规则,是业务软件核心。

从我对需求的经验看,业务概念,规则不是业务的核心。客户要求解决的问题才是核心。

而且,有些业务概念都是应用工程师自己加上去的,不对应用户工作,随着需求的演进,随时都会被调整。

tearoffhu
2009-05-20 12:49
为什么还是没人回复呢。

是我问的问题有什么错误吗?

还是我说的东西没有考虑的价值?

听说这边高手多我才在这里发文章的,

我们天津C++程序员做OO研究的不多,大都研究算法。真希望能有机会跟高手交流。

谢谢

ACoder
2009-05-20 13:38
我不是高手,不过很想了解一下你认为在这个项目中最难点是什么??

tearoffhu
2009-05-20 13:40
您说的是哪个项目?

tearoffhu
2009-05-21 07:39
我看了ACoder您的一些帖子。

我觉得很多观点跟我想法很像。

能把QQ号或是MSN,Skype号给我吗?

方便交流。

谢谢

usejava
2009-05-21 13:16
在任何确定时间,需求也都是确定的,所以有baseline。当然未来需求会有变化,所以有revision。

未来的变化可以预测,但是无法确定。就象你所说的业务员可以估计需求变化的方向。估计和方向都是不确定的。这种估计不是需求。对于当前需求来讲,这些潜在变化是risk,因而不需要再需求文档描述。

设计是基于需求的。Risk在设计中的作用在于,Risk需要确定应对方案,这种方案可能就是采用接口来屏蔽未来实现的变化。当需求实际变化,也就是Risk实际发生时,这种设计可以把影响控制在尽可能小的范围。

tearoffhu
2009-05-22 06:51
我的问题是 基于需求(不考虑风险的部分)设计对项目有什么作用?

在我看来 设计最大的用途就是规避风险,别的用途不多。

usejava
2009-05-22 08:53
设计是为项目服务的,而项目的目的是满足需求,规避风险是附加效果。

避免风险的最简单方法是不做项目,那就不会有任何项目失败的风险了。

猜你喜欢
2Go 1 2 下一页