低内聚高耦合的衡量指标

衡量模块的 低内聚和 高耦合程度需要通过具体的指标和观察点来判断。以下是常见的量化或定性分析指标，以及实际场景中的表现特征：

---

一、低内聚（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、C同步修改（如数据库表结构变更导致多个服务需适配）。

2. 设计层面的表现

• 接口与实现强绑定
  • 模块直接依赖具体实现类而非接口（如new MySQLRepository()而非IRepository）。
• 全局状态或共享数据
  • 多个模块依赖同一个全局变量或数据库表（如全局static Config对象）。

3. 量化指标

• 耦合度（Coupling Between Objects, CBO）
  • 统计一个类直接依赖的其他类的数量，CBO > 5通常表示高耦合。
• 响应集（Response Set, RS）
  • 修改一个类时可能影响的其他类的数量，RS值越高耦合越强。
  • 工具：SonarQube、Understand。

---

三、实际场景中的典型特征

低内聚高耦合的系统表现

1. 牵一发而动全身
   • 修改一个小功能需同步修改多个模块。
2. 测试困难
   • 模块无法独立测试，必须启动大量依赖服务。
3. 复用性差
   • 模块难以移植到其他系统（如OrderModule强依赖特定日志服务）。

---

四、改进方向

降低耦合

• 依赖注入（DI）：通过接口解耦具体实现。
• 事件驱动：用消息队列（如Kafka）替代直接调用。
• 模块化拆分：遵循单一职责原则重构模块。

提高内聚

• 功能重组：将相关代码合并到同一模块（如将分散的「权限校验」逻辑集中到AuthModule）。
• 领域驱动设计（DDD）：按业务领域划分模块边界。

---

五、工具与实践建议

1. 代码分析工具
   • SonarQube、NDepend、ArchUnit（检测架构约束）。
2. 可视化依赖
   • 使用Dependency Structure Matrix (DSM)或工具（如CodeMaTIC）生成模块依赖矩阵。
3. 团队协作
   • 定期进行代码评审，检查新代码是否加剧耦合。

---

总结

• 低内聚：看模块内部是否功能分散、职责模糊。
• 高耦合：看模块间是否依赖复杂、难以独立变更。
• 关键指标：LCOM、CBO、RS、依赖数量、调用链深度。

通过量化指标和设计原则，可以客观评估系统的内聚和耦合问题，并针对性优化。