某些软件指标的建议阈值
我在互联网上搜索以下知名软件产品指标阈值的一些建议：
- 方法中缺乏内聚性（对于指标的 Henderson-Sellers 变体）
- 类中继承的方法数 类中
- 重写方法的数量
- 类中新添加的方法的数量
但是我没有找到任何方法。我对第一个特别感兴趣。有人知道这件事吗？ 提前致谢，马丁
I was searching the internet for some suggestions for thresholds for the following well-known software product metrics:
- Lack of Cohesion in Methods (for the Henderson-Sellers variant of the metric)
- Number of Inherited Methods in a Class
- Number of Overriden Methods in a Class
- Number of Newly Added Methods in a Class
However I failed to find any. I am particularly interested in the first one. Does anybody know something about this ?
Thanks in advance, Martin
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
NDepend 建议如下：
http://www.ndepend.com/Metrics.aspx#LCOM
NDepend suggests the following:
http://www.ndepend.com/Metrics.aspx#LCOM
此参考给出了 LCOM 和 LCOMHS 的值。它说
我不确定在处理 Java Bean 时该措施的效果如何，因为 Java Bean 很可能有大量的 getter 和 setter，每个都处理单个属性。
This reference gives for values for LCOM and LCOMHS. It says
I'm not sure how well this measure works when dealing with a Java Bean, which could well have a large number of getters and setters each dealing with a single property.
请注意，对于“相同”指标，不同工具生成的数字存在很大差异。有时这是因为原始来源不精确，有时是因为工具制造商“改进”了度量标准。大多数度量工具都有默认阈值。我会使用它，除非你有充分的理由不这样做。
我对大班级进行了大量的凝聚力测量。我认为我从未见过高于 1.0 的 LCOM-HS 测量值，但我认为您可能会在小班级中看到它们（您可能不太关心内聚性）。就我个人而言，我使用的阈值是 0.8，但这是任意的。我读过很多关于凝聚力的论文，但很少看到提到阈值。这包括我读过的亨德森-塞勒斯论文。
djna 是正确的，他说内聚性测量会给 JavaBeans 和其他“数据存储”类带来较差的分数。此外，许多凝聚力测量（包括 LCOM-HS）没有考虑一些可能导致误导性的低分的因素。例如，许多实现不考虑与继承成员的关系。 LCOM-HS 和许多其他方法也过度依赖方法访问字段的方式。例如，如果您编写一个类，其中的方法主要通过其参数与“数据”交互，您将得到一个看起来高度非内聚的类；而实际上，它可能是经过精心设计的。
至于你提到的其他指标，我没有看到任何建议。我环顾四周，我看到的关于 XXX 方法数量的唯一建议是每个类最多 20 个（没有关于实例与静态、重写等的详细信息）。
这里列出了一些涉及 OO 指标的论文，主要是凝聚。
Be aware that there is a lot of variability in the numbers produced by various tools for the "same" metric. Sometimes this is because the original source was imprecise and sometimes it is because the tool maker "improved" the metric. Most metric tools have a default threshold. I'd use that unless you have a strong reason not to.
I do a lot of cohesion measurement for large classes. I don't think I have ever seen an LCOM-HS measurement above 1.0, but I think you may see them for tiny classes (where you probably don't really care that much about cohesiveness). Personally, I use a threshold of 0.8, but that's arbitrary. I've read a lot of papers about cohesion, and I have seen very few thresholds mentioned. This includes the Henderson-Sellers papers that I've read.
djna is correct when he says that cohesion measures will give poor scores for JavaBeans and other "data storage" classes. Furthermore, many cohesion measurements, including LCOM-HS do not consider some things that may lead to misleadingly poor scores. For example, many implementations don't consider relationships with inherited members. LCOM-HS and many others also have an over-reliance on how methods access fields. For example, if you write a class where the methods mainly interact with "data" through their arguments, you will get what appears to be a highly non-cohesive class; whereas in reality, it may be well-designed.
In terms of the other metrics you mentioned, I've seen no recommendations. I've looked around, and the only recommendation I've seen pertaining to the number of XXX methods is a maximum of 20 per class (no detail as to instance vs. static, overridden, etc.).
Here is a list of some papers dealing with OO metrics, mostly cohesion.