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

?

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

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

?

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

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

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

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

?

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

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

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

現在的編程語言是基于文本的, 或者其實也是基于文件系統的. 文件系統是一棵樹, 每個葉子節點只能隸屬于一個父節點, 樹的結構只能按照一個維度優化. 語言本身的元數據也不夠豐富. 這些都限制了能夠生成各種視圖的IDE的出現

?

這應該只是約束理論的一個實例.