内聚是什么
内聚衡量模块内部各元素之间的相关程度，是模块设计的核心指标之一。从弱到强大致分为：偶然内聚（元素之间没有实质关系）、逻辑内聚（按类别把选择逻辑打包）、时间内聚（同一时间执行）、过程内聚（按执行顺序）、通信内聚（操作同一份数据）、顺序内聚（前一步输出是后一步输入）、功能内聚（所有元素共同完成单一功能）。设计目标是把模块做成一件事，而不是把「看起来都是工具类方法」的东西凑在一起。
基本信息
| 衡量对象 | 单个模块或类内部的元素相关性 |
|---|---|
| 最强形态 | 功能内聚：所有元素共同服务一个明确职责 |
| 最弱形态 | 偶然内聚：元素之间没有实质关系，只是被放在一起 |
| 判断方法 | 试着用一句话描述模块职责，说不清说明内聚偏低 |
| 配套指标 | 内聚与耦合要一起看：高内聚低耦合才是可用目标 |
典型使用场景
- 模块拆分评审：用职责描述检验拆分后的模块是否各自聚焦
- 工具类治理：把不断膨胀的 Utils 按变化原因重新拆分
- 服务边界设计：把同一业务能力的逻辑收拢到一处
- 重构排期：识别内聚偏低的热点文件并排入治理计划
- 代码评审：新增方法前先问它是否属于该模块的职责
- 包结构设计：按业务能力组织模块，避免按技术类型平铺
内聚等级
| 等级 | 含义 | 示例 |
|---|---|---|
| 功能内聚 | 所有元素共同完成单一功能 | 金额计算模块 |
| 顺序内聚 | 上一步输出是下一步输入 | 先解析再校验的处理链 |
| 通信内聚 | 多个操作作用于同一份数据 | 同时读写同一订单结构 |
| 逻辑内聚 | 按类别打包的选择逻辑 | 各种格式导出的函数集合 |
| 偶然内聚 | 元素之间没有实质关系 | 杂项方法堆成的工具类 |
拆分判断要点
拆分判断要点
# 1 一句话职责：能否用一句话说清模块做什么，说不清就该拆
# 2 变化原因：变更是否总是一起发生，总一起变才适合放在同一模块
# 3 命名检验：名字里出现 And、Utils、Common、Helper 时，检查是否偶然内聚
# 4 依赖方向：拆分后模块间调用关系是否更简单，而不是引入更多跳转
# 5 反例警示：为提升内聚而强行拆成极小的模块，会让调用链与样板代码膨胀
# 6 复查节奏：模块随业务演进会再次失焦，定期用职责描述重新对照内聚低通常伴随「工具类」不断膨胀：按变化原因把方法重新分组，比继续往同一个类里加方法更有长期价值。
内聚不是越高越好：过度拆分会让模块间调用关系变复杂，判断标准是拆分后整体是否更容易理解与修改。