某些软件指标的建议阈值

Question

我正在互联网上搜索以下众所周知的软件产品指标阈值的一些建议：

• 方法缺乏凝聚力（针对衡量标准的Henderson-Sellers变体）
• 类中的继承方法数
• 类中的重叠方法数
• 类中新增方法的数量

然而我没有找到任何。我对第一个特别感兴趣。有人知道这个吗？ 提前谢谢，马丁

Answer 1

NDepend建议如下：

http://www.ndepend.com/Metrics.aspx#LCOM

Answer 2

这个reference给出了LCOM和LCOMHS的值。它说

  

  
• LCOM = 1 - （总和（MF）/ M * F）
  
• LCOM HS =（M - sum（MF）/ F）（M-1）
  

     

其中：

     

  
• M是类中的方法数（静态和实例）   方法计算，它也包括   构造函数，属性   getters / setters，事件添加/删除   方法）。
  
• F是班级中实例字段的数量。
  
• MF是访问特定类的类的方法数   实例字段。
  
• Sum（MF）是该类所有实例字段的MF之和。
  

     

这些背后的基本理念   公式可以表述如下：a   如果所有这一切都是完全凝聚力的   方法使用其所有实例字段

我不确定这个措施在处理Java Bean时效果如何，它可能会有大量的getter和setter处理单个属性。

Answer 3

请注意，各种工具为“相同”指标生成的数字存在很多差异。有时这是因为原始来源不精确，有时是因为工具制造商“改进”了指标。大多数度量工具都有默认阈值。我会使用它，除非你有充分的理由不这样做。

我为大班做了很多内聚测量。我认为我从未见过LCOM-HS测量值高于1.0，但我认为你可能会看到它们用于小类（你可能并不太关心凝聚力）。就个人而言，我使用0.8的阈值，但这是任意的。我已经阅读了很多关于凝聚力的论文，我看到很少提及阈值。这包括我读过的Henderson-Sellers论文。

djna是正确的，当他说内聚措施会给JavaBeans和其他“数据存储”类带来不好的分数。此外，包括LCOM-HS在内的许多内聚测量都没有考虑可能导致误导性得分差的一些事情。例如，许多实现不考虑与继承成员的关系。 LCOM-HS和许多其他人也过度依赖方法访问字段的方式。例如，如果你编写一个类，其中方法主要通过参数与“数据”交互，那么你将得到一个看起来非常有凝聚力的类;而实际上，它可能是精心设计的。

就您提到的其他指标而言，我没有看到任何建议。我环顾四周，我看到的关于XXX方法数量的唯一建议是每个类最多20个（没有关于实例与静态，重写等的详细信息）。

Here是一些关于面向对象指标的论文清单，主要是凝聚力。