关于DCI的理解

12-02-01 lovejdon
早就听说了DCI,刚开始接触确实云里雾里的,感觉明白了,其实还是没有深刻理解。今天再次在论坛里找了BANQ大哥关于DCI讨论的帖子细细品品,结合QI4J中对what's an object anyway?的论述,又有了深刻理解。这里把我的想法说说,也请BANQ和论坛朋友帮我分析下其中的不足之处,多谢!

OO带给我们很多的好处,程序的健壮,维护的便利,以及OO思想。但是再接触DCI提出的所谓算法的讨论时,发现我们虽然推崇的OO是多么的好,对过程式开发多么的抵触,但是我发现一点,oo开发中,细化的对象中细小的琐碎方法组合会完成一个操作,而当我们读程序的时候,发现很多单一业务在OO中反映的是各个对象的交互和组合拼凑,这细碎的划分是为了更好的划分职责,但是所付出的代价是算法的内聚性,或者说用例中提到的行为已经被撕裂粉碎。这个过程也是一种需求原型失真的一种体现。(个人理解)。而如果要保持这种算法的高内聚,把算法包含在一个对象里,实际我们又是在写过程式的代码而已,只是以对象的形式出现,而不是函数式的。当然开发中通过接口的方式暴露大的算法接口,然后内部细化的方式可以解决算法内聚度不高的问题,但是从职责角度讲,有些东西是没法定位具体所属对象的。而DCI的思想是提到了角色的概念或者可以理解为行为的集合。而这个行为就是算法

我先前对算法的理解就是怎么做,怎么实现算法,是这样一个过程。而DCI中提到的算法是“做什么”,“做什么”意味着我们不需要知道细节,就类似看interface就知道是干什么用,完成什么功能。具体怎么做取决于implementation。也就是实现接口的类,这个类根据不同的环境会有不同的实现,但是完成的功能是一样的。策略模式中提到的算法指的就是“怎么做”,而策略模式中接口或者抽象类中定义的行为则是“做什么”。从这个角度讲,“算法“的定位对于理解DCI是一个关键点。

既然这里知道了算法是作为行为存在的,那么这个行为涉及到的数据模型就理解为DCI中的data model.因为我们做一件事情必须会与数据打交道。这个被称作"是什么",实际”是什么“是在描述一个物,这个物或者是实物或者是想象中的,这个也很好理解。最难理解的就是这个context的由来.

把算法想成”做什么“,在OO中理解为接口定义的行为。把这个算法中涉及的物想象成”是什么“,在OO中理解为一个操作的数据data,那么我们现在缺得是什么,是利用data去完成这个算法。算法在这里只是一个空壳子而已,没有具体的东西。就好比给你一堆木头和一个任务”盖房子“一样,你要做的是如何盖这个房子,那么你要考虑在什么环境下去盖什么样子的,那么房子是依赖于所处环境的,比如在海边会是什么样子(防水),在沙漠会是什么样子(防沙,防风),在闹市是什么样子(防噪音,防震等),这就取决于所处环境,在DCI中就是CONTEXT的概念。这个CONTEXT就是环境。这是我个人的理解,但是绕来绕去。好像和以往的OO思想里面的多态没啥区别,多态也是一种动态的行为,只是没有提到环境的概念,DCI中不同的地方是提出了角色的概念,角色的职责就是行为的集合或者就是算法的集合,角色不同,行为就不同。但是在OO中多态,是确定了行为后,实现的不同,所以OO中的算法是怎么做的问题,而DCI中的算法是做什么的问题。角色不同,算法不同,算法不同,做的东西就不同。

DCI个人体会到的好处真的是从行为出发,与需求用例结合的很紧密,分析需求的时候,人们习惯的分析都是从参与者(角色)在一个场景(context)中利用一些设备或者数据(data model)完成一个或者多个动作(算法(这个角色的职责)),所以个人感觉DCI的思想是比目前OO思想下更贴近业务需求的分析,如果这个能在JAVA语言下直接翻译或者经过尽可能少的转化得来,那么我们开发真的会聚焦于需求,而不是聚焦于技术细节。

以上是我对DCI的理解,有不到位的地方请各位指出,也希望从各位的建议中更深刻理解DCI,更好的学习。

    

banq
2012-02-01 15:12
2012年02月01日 14:33 "@lovejdon"的内容
但是在OO中多态,是确定了行为后,实现的不同,所以OO中的算法是怎么做的问题,而DCI中的算法是做什么的问题。角色不同,算法不同,算法不同,做的东西就不同。

DCI个人体会到的好处真的是从行为出发,与需求用例结合的很紧密 ...

写得不错,很有见解。

猜你喜欢