高内聚是有极限的. 当代码在一个维度上高度内聚的时候, 在其它维度上是发散的. -- 代码内聚设计的不确定性原理

 

大家都知道量子力学的不确定性原理: 在微观世界里, 有几对物理量不能同时精确的测定, 包括速度与位置, 以及能量与时间. 比如当我们精确的测定一个粒子的速度使其误差很小的时候, 我们对其位置的测量误差从0到正无穷都有可能, 换句话说, 此时粒子可能位于宇宙的任何地方, 这里的极限就是二者误差的乘积总是大于一个被称为普朗克常数的数. 

代码的设计有时会感到同样的张力: 无法做到完全的内聚. 当代码在一个维度上高度内聚的时候, 在其它维度上是发散的或耦合的. 无论是逻辑设计还是物理设计.

 

看一个代码逻辑设计的例子, 就是结构和行为.

当代码在结构上内聚的时候, 在行为上是发散的. 主流的面向对象编程范式是按照结构优化的, 看一下你的代码中的class的名字, 大都是名词, 是一个事物, 表达了What the system is. 但这个系统具有什么样的行为, 能做什么事, What the system does, 却被切片, 分散到系统的各个角落. 我们或许能说出系统的静态结构是什么样子, 却要花费更多的精力才能搞清楚系统做了什么, 能做什么, 结构间的交互是什么样子.

面向过程的编程范式是按照行为优化的. 过程的名字通常是动词, 表达了 What the system does. 系统的静态结构则被掩藏在了行为之后

DCI有助于解决代码逻辑设计的内聚问题.

 

一个代码物理设计的例子, 就是按照业务还是技术架构层次来划分模块和目录结构

当我们按照feature来划分目录结构的时候, 相同的技术架构层次的代码会被分到不同的目录中. 比如数据访问层的代码会分散到各个feature的目录中.

当我们按照技术层次架构来划分目录的时候, 同一个feature的代码会被分到不同目录中, 而同一个目录中会包含多个feature的代码. 比如流行的MVC框架的缺省目录结构都是所有的controller放在一起, 所有的model放在一起等等. 当我需要看一个feature的完整实现时, 需要从不同目录中挑出不同文件来查看.

现在的编程语言是基于文本的, 或者其实也是基于文件系统的. 文件系统是一棵树, 每个叶子节点只能隶属于一个父节点, 树的结构只能按照一个维度优化. 语言本身的元数据也不够丰富. 这些都限制了能够生成各种视图的IDE的出现

 

这应该只是约束理论的一个实例.