內聚的極限: 軟體開發的不確定性原理

高內聚是有極限的. 當代碼在一個維度上高度內聚的時候, 在其它維度上是發散的. -- 代碼內聚設計的不確定性原理

 

大家都知道量子力學的不確定性原理: 在微觀世界裡, 有幾對物理量不能同時精確的測定, 包括速度與位置, 以及能量與時間. 比如當我們精確的測定一個粒子的速度使其誤差很小的時候, 我們對其位置的測量誤差從0到正無窮都有可能, 換句話說, 此時粒子可能位於宇宙的任何地方, 這裡的極限就是二者誤差的乘積總是大於一個被稱為普朗克常數的數. 

代碼的設計有時會感到同樣的張力: 無法做到完全的內聚. 當代碼在一個維度上高度內聚的時候, 在其它維度上是發散的或耦合的. 無論是邏輯設計還是實體設計.

 

看一個代碼邏輯設計的例子, 就是結構和行為.

當代碼在結構上內聚的時候, 在行為上是發散的. 主流的物件導向編程範式是按照結構最佳化的, 看一下你的代碼中的class的名字, 大都是名詞, 是一個事物, 表達了What the system is. 但這個系統具有什麼樣的行為, 能做什麼事, What the system does, 卻被切片, 分散到系統的各個角落. 我們或許能說出系統的靜態結構是什麼樣子, 卻要花費更多的精力才能搞清楚系統做了什麼, 能做什麼, 結構間的互動是什麼樣子.

面向過程的編程範式是按照行為最佳化的. 過程的名字通常是動詞, 表達了 What the system does. 系統的靜態結構則被掩藏在了行為之後

DCI有助於解決代碼邏輯設計的內聚問題.

 

一個代碼實體設計的例子, 就是按照業務還是技術架構層次來劃分模組和目錄結構

當我們按照feature來劃分目錄結構的時候, 相同的技術架構層次的代碼會被分到不同的目錄中. 比如資料訪問層的代碼會分散到各個feature的目錄中.

當我們按照技術層次架構來劃分目錄的時候, 同一個feature的代碼會被分到不同目錄中, 而同一個目錄中會包含多個feature的代碼. 比如流行的MVC架構的預設目錄結構都是所有的controller放在一起, 所有的model放在一起等等. 當我需要看一個feature的完整實現時, 需要從不同目錄中挑出不同檔案來查看.

現在的程式設計語言是基於文本的, 或者其實也是基於檔案系統的. 檔案系統是一棵樹, 每個葉子節點只能隸屬於一個父節點, 樹的結構只能按照一個維度最佳化. 語言本身的中繼資料也不夠豐富. 這些都限制了能夠產生各種視圖的IDE的出現

 

這應該只是約束理論的一個執行個體.