關於DCI的理解

lovejdon發表於2012-02-01
早就聽說了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，更好的學習。

相關文章