软件思想的进化和相通

11-06-08 IceQi
              

我知道的软件思想至今发展的主要过程:面向过程 -》OO-》DDD-》DCI

始终是一个进化的过程,OO解决了面向过程的封装,但他依然是基于静态的分析;DDD提供了面向应用业务的分析指导,但是他没有直接提供解决对象变化的指导;DCI提供了系统模型分析的指导,他没有解决。。。。。必然有,但我还没有看到。。。。。

思想是渐进式的,对于思想的理解也是渐进的。

OO开始提供了思想基础但是缺少实践方式,在以后的时间里他始终影响着软件的思考方式。DCI的上下文中角色的转变其实也源于此。在传统上我们分析了角色的职能,但是往往忽视了“本体”与“角色”间的区别,从而得到了一个本体中需要实现多个角色的分析结果也是困惑。

DCI中说明了在不同的上下文中本体的角色是可以被替换的,这样本体和角色又再次成为了分隔的独立,互不依赖。如果角色可以在运行时刻被赋予本体,那么AOP、SOA与DCI也建立了关联,同时IOC也成为了将本体组装角色的实践。在各个思想和实践方式中对的内容将共同的被保留和进化,并最终必然的找到契合点。

我认为软件可以理解位自然世界的映射,所有需要软件解决的问题和解决方法必然存在于自然世界中,OO表达了这样的思想。OO是基础和思想的源泉,同时在今后很久(或者永久,除非诞生了全新的软件实践方式)都将是我们思想基础。后来者在研究和学习各种名词和思想之前应该认真深入的思考OO,如果在这个步骤上出现了失误和偏差在后面的过程中弥补是需要付出很多代价的。

时间很短,简单写了。

              

5
banq
2011-06-10 13:51

最后一句写得很好,错过了补课就很吃力。越到后来新的概念理解起来越困难,其实他们也有自己的发展和进化轨道。

showerxp
2011-06-10 17:56

只认为DDD和DCI是OO的一个子集。

OO的诞生就是于对复杂业务流程用面向过程处理力所不能及的时候,提出运用抽象和封装的思想运用到编程中去。所以,可以说,OO原本关注点就是客观世界的业务模型。DDD是在之后,层出不穷的技术、方法论,导致OO的“原本关注点”被淡化甚至迷失之后,重新提出要重点回到对客观事物本身的关注。

一下引述一下《精简版》的序文

“在 DDD 以及传统 OO 的观点中,业务而不是技术是一个开发团 队首先要关注的内容,众多的框架和平台产品也在宣称把开发人员 解放出来,让他们有更多的精力去关注业务”

“你就会发现,DDD 其实没有什么太多的 新鲜玩意,它更多地是可以看作是面向对象思潮的回归和升华”

“"DDD"作为传统 OO 范型的探索和升华版,也存在着一些 不足和未涉及的领域……”

而作为DCI,我没有深入研究,只是认为它将处理过程也用OO建模而已。另外,将用例与Context关联,我持有异议。用例的目标单一——重现捕获需求过程,如果还要考虑之后Context,并作为DCI建模重要内容,势必淡化用例的初始目标。

SpeedVan
2011-06-11 09:26

2011年06月10日 17:56 "@showerxp"的内容
用例的目标单一——重现捕获需求过程,如果还要考虑之后Context,并作为DCI建模重要内容,势必淡化用例的初始目标。 ...

用例还是原来的用例,Context和用例关联并没有影响用例本身。关联是因为在原来的用例上可以直接发现Context。可以这么想:用例不知道Context,Context却知道用例——获取用例的人只知道这是用例,但建模者却在这用例中获得更多信息而已。

当然,不排除为了更好的获取Context来调整用例,但我不认为用例失去本意了。

showerxp
2011-06-11 10:54

用例本身作为捕获需求的半形式化工具,其根本任务就是重视捕获需求过程,这一过程使得我们更好的认知问题域中的复杂业务处理流程。重现捕获需求如此重要,以至于该过程的结果——用例本身都显得不太重要了。这样DCI把关注重点放在这种主观意识理解的产物——用例身上,势必需要对用例赋予新的责任。比如用例要比较稳定,不能时常修改,而认知陌生事物过程本身就是一个由浅入深的过程,所以用例不可能一步到位,不做修改或者删减;比如用例中的内容要便于软件实现,势必掺杂代码思维,而弱化业务需求本身……

以上是我对DCI肤浅认识,现在看来,需要一个DCI实现案例,做具体分析。我说的案例当然包括用例编写过程,而不是涉及到用例只是一张用例图简单带过。

3Go 1 2 3 下一页