为什么方法缺乏内聚 (LCOM) 包括 Getter 和 Setter
我正在查看 LCOM 指标,如下所示,
http://www.ndepend.com/Metrics.aspx< /a>
所以我们要说几件事,
1) 如果类的所有方法都使用其所有实例字段,则该类是完全内聚的 2) 静态方法和实例方法都计算在内,还包括构造函数、属性 getter/setter、事件添加/删除方法
如果我查看这样的类,
public class Assessment
{
public int StartMetres { get; set; }
public int EndMetres { get; set; }
public decimal? NumericResponse { get; set; }
public string FreeResponse { get; set; }
public string Responsetype { get; set; }
public string ItemResponseDescription { get; set; }
public string StartText { get; set; }
public decimal? SummaryWeight { get; set; }
}
它会得到 0.94 的糟糕分数,因为每个 getter 和 setter 都不会访问“所有其他实例字段”。
它是这样计算的,
accessAverage - methodCount / 1 - methodCount
(2 - 17) / (1 - 17) = 0.94 (rounded)
我不理解这个指标,为什么它应该包括 getter 和 setter? getter 和 setter 始终只能访问一个实例字段。
I am looking at the LCOM metric as shown here,
http://www.ndepend.com/Metrics.aspx
So we are saying a few things,
1) A class is utterly cohesive if all its methods use all its instance fields 2) Both static and instance methods are counted, it includes also constructors, properties getters/setters, events add/remove methods
If I look at a class such as this,
public class Assessment
{
public int StartMetres { get; set; }
public int EndMetres { get; set; }
public decimal? NumericResponse { get; set; }
public string FreeResponse { get; set; }
public string Responsetype { get; set; }
public string ItemResponseDescription { get; set; }
public string StartText { get; set; }
public decimal? SummaryWeight { get; set; }
}
It gets a bad score of 0.94 because each getter and setter doesn't access 'all of the other instance fields'.
It is calculated like this,
accessAverage - methodCount / 1 - methodCount
(2 - 17) / (1 - 17) = 0.94 (rounded)
I am not understanding this metric, why should it include getters and setters? A getter and setter will always only access one single instance field.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这表明,如果你盲目地走向极端,那么每个软件指标都是有缺陷的。
当你看到一个类时,你就知道这是一个“不连贯”的类。例如:
这显然是一个不内聚的类,因为它包含两个不需要彼此在一起的数据。
但是,虽然我们很明显这个类是不内聚的,但如何让软件程序来确定不内聚呢?如何判断上面的类是不内聚的,而这个类却不是?
他们提出的指标确实可以检测到不连贯性,但也会出现误报。
如果您认为这个指标很重要怎么办?您可以创建一个仅包含字段的“CustomerData”类,以及一个将数据字段公开为属性的“Customer”类。
但如果我正在玩这个游戏,我也可以将其应用到缺乏凝聚力的示例中:
真的,我认为最好了解什么是凝聚力,以及为什么它是一个有价值的目标,但也要了解软件工具无法正确衡量它。
This demonstrates that every software metric is flawed if you blindly take it to its extreme.
You know an "incohesive" class when you see one. For example:
This is obviously an incohesive class, because it contains two pieces of data that don't need to be with one another.
But while it's obvious to us that this class is incohesive, how can you get a software program to determine incohesion? How would it tell that the above class is incohesive, but this isn't?
The metric they came up with certainly detects incohesion, but also comes up with false positives.
What if you decided this metric was important? You could create a "CustomerData" class containing just fields, and a "Customer" class that exposes the data fields as properties.
But if I'm playing this game, I can apply it to the incohesive example as well:
Really, I think it's best to understand what cohesion is, and why it's a worthwhile goal, but also understand that a software tool can not properly measure it.