关于DCI的理解

早就听说了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，更好的学习。