文章目录
-
-
- [**一、低内聚（Low Cohesion）的衡量指标**](#一、低内聚（Low Cohesion）的衡量指标)
-
- [**1. 代码层面的指标**](#1. 代码层面的指标)
- [**2. 设计层面的表现**](#2. 设计层面的表现)
- [**3. 量化指标（需工具支持）**](#3. 量化指标（需工具支持）)
- [**二、高耦合（High Coupling）的衡量指标**](#二、高耦合（High Coupling）的衡量指标)
-
- [**1. 代码层面的指标**](#1. 代码层面的指标)
- [**2. 设计层面的表现**](#2. 设计层面的表现)
- [**3. 量化指标**](#3. 量化指标)
- **三、实际场景中的典型特征**
- **四、改进方向**
- **五、工具与实践建议**
- **总结**
-
衡量模块的 低内聚 和 高耦合 程度需要通过具体的指标和观察点来判断。以下是常见的量化或定性分析指标，以及实际场景中的表现特征：
一、低内聚（Low Cohesion）的衡量指标
内聚性指模块内部元素（函数、类、组件）之间的功能相关性。低内聚表现为模块职责分散、功能混杂。
1. 代码层面的指标
-
方法/类的不相关性
- 模块中的方法或类在功能上无直接关联（如一个
UserService同时处理「登录」「订单统计」「日志导出」）。 - 检测工具：代码静态分析工具（如SonarQube）的「类职责过多」警告。
- 模块中的方法或类在功能上无直接关联（如一个
-
代码变更的扩散性
- 修改一个需求时，需要频繁改动同一模块内的多个文件或方法。
- 示例 ：调整用户权限逻辑时，需同时修改
UserService、OrderService和AuthService，说明权限逻辑分散。
-
代码复用率低
- 模块内部代码无法被其他部分复用，重复实现相似功能。
2. 设计层面的表现
- 模块名称模糊
- 模块名无法清晰概括其功能（如
CommonUtils、Manager）。
- 模块名无法清晰概括其功能（如
- 功能边界不明确
- 模块同时处理多个业务领域的问题（如
PaymentModule中包含「物流跟踪」逻辑）。
- 模块同时处理多个业务领域的问题（如
3. 量化指标（需工具支持）
- LCOM（Lack of Cohesion of Methods）
- 通过计算类中方法间共享字段的比例来评估内聚性，值越高内聚性越低（LCOM > 1通常表示低内聚）。
- 工具：JDepend、NDepend、SourceMonitor。
二、高耦合（High Coupling）的衡量指标
耦合度指模块间依赖关系的强度。高耦合表现为模块间直接依赖过多，难以独立修改或替换。
1. 代码层面的指标
-
导入依赖数量
- 模块直接依赖的其他模块/类数量过多（如一个类导入数十个外部类）。
- 示例 ：
OrderService直接依赖UserDB、PaymentAPI、InventoryCache、LogUtil等。
-
跨模块调用链深度
- 模块A调用模块B，模块B又调用模块C，形成长调用链（如
A → B → C → D）。 - 检测工具：调用链分析（APM工具如SkyWalking、Jaeger）。
- 模块A调用模块B，模块B又调用模块C，形成长调用链（如
-
传递性依赖
- 修改模块A会迫使模块B、C同步修改（如数据库表结构变更导致多个服务需适配）。
2. 设计层面的表现
- 接口与实现强绑定
- 模块直接依赖具体实现类而非接口（如
new MySQLRepository()而非IRepository）。
- 模块直接依赖具体实现类而非接口（如
- 全局状态或共享数据
- 多个模块依赖同一个全局变量或数据库表（如全局
static Config对象）。
- 多个模块依赖同一个全局变量或数据库表（如全局
3. 量化指标
- 耦合度（Coupling Between Objects, CBO）
- 统计一个类直接依赖的其他类的数量，CBO > 5通常表示高耦合。
- 响应集（Response Set, RS）
- 修改一个类时可能影响的其他类的数量，RS值越高耦合越强。
- 工具：SonarQube、Understand。
三、实际场景中的典型特征
低内聚高耦合的系统表现
- 牵一发而动全身
- 修改一个小功能需同步修改多个模块。
- 测试困难
- 模块无法独立测试，必须启动大量依赖服务。
- 复用性差
- 模块难以移植到其他系统（如
OrderModule强依赖特定日志服务）。
- 模块难以移植到其他系统（如
四、改进方向
降低耦合
- 依赖注入（DI）：通过接口解耦具体实现。
- 事件驱动：用消息队列（如Kafka）替代直接调用。
- 模块化拆分：遵循单一职责原则重构模块。
提高内聚
- 功能重组 ：将相关代码合并到同一模块（如将分散的「权限校验」逻辑集中到
AuthModule）。 - 领域驱动设计（DDD）：按业务领域划分模块边界。
五、工具与实践建议
- 代码分析工具
- SonarQube、NDepend、ArchUnit（检测架构约束）。
- 可视化依赖
- 使用
Dependency Structure Matrix (DSM)或工具（如CodeMaTIC）生成模块依赖矩阵。
- 使用
- 团队协作
- 定期进行代码评审，检查新代码是否加剧耦合。
总结
- 低内聚：看模块内部是否功能分散、职责模糊。
- 高耦合：看模块间是否依赖复杂、难以独立变更。
- 关键指标：LCOM、CBO、RS、依赖数量、调用链深度。
通过量化指标和设计原则，可以客观评估系统的内聚和耦合问题，并针对性优化。