oop - 度量和面向对象的编程

Question

我想知道是否有人经常使用指标来验证其代码/设计。例如，我想我会使用：

• 每个方法的行数（< 20）
• 每个方法的变量数 (< 7)
• 每个方法的参数数量 (< 8)
• 每个类的方法数（< 20）
• 每个类的字段数（< 20）
• 继承树深度 (< 6)。
• 方法缺乏凝聚力

这些指标中的大多数都非常简单。

您对这种措施有什么政策？您是否使用工具来检查他们的（例如 NDepend）？

Answer 1

在我看来，对这些值施加数值限制（正如你似乎暗示的那样）不是一个好主意。如果有重要的 switch 语句，方法中的行数可能非常多，但方法仍然简单正确。如果字段很简单，则类中的字段数可以适当地非常大。有时，五级继承可能太多了。

我认为最好分析类内聚（越多越好）和耦合（越少越好），但即便如此，我还是怀疑这些指标的效用。经验通常是一个更好的指南（尽管无可否认，这很昂贵）。

Answer 2

我在您的列表中没有看到的一个指标是 McCabe 的圈复杂度。它衡量给定功能的复杂性，并与错误相关。例如，一个函数的高复杂度分数表明：1）它可能是一个有问题的函数，2）它可能很难正确修复（例如修复会引入它们自己的错误）。

最终，指标最好在总体水平上使用——比如控制图。您寻找控制限上下的点以识别可能的特殊情况，然后查看详细信息。例如，具有高圈复杂度的函数可能会导致您查看它，只是发现它是合适的，因为它是具有多种情况的调度程序方法。

Answer 3

指标管理不适用于人员或代码；没有任何指标或绝对值将始终有效。请不要让对指标的迷恋分散了对代码质量的真正评估。指标似乎可以告诉您有关代码的重要信息，但它们能做的最好的事情就是提示要调查的区域。

这并不是说指标没有用。指标在变化时最有用，可用于寻找可能以意想不到的方式变化的区域。例如，如果您突然从 3 级继承变为 15，或者每个方法的 4 个参数变为 12，请深入挖掘并找出原因。

示例：更新数据库表的存储过程可能具有与表中的列一样多的参数；此过程的对象接口可能具有相同的接口，或者如果存在表示数据实体的对象，则它可能具有一个接口。但是数据实体的构造函数可能具有所有这些参数。那么这个指标会告诉你什么？不多！而且，如果您在代码库中有足够多的此类情况，那么目标平均值将被吹得水泄不通。

所以不要依赖指标作为任何事物的绝对指标；没有什么可以替代阅读/审查代码。

Answer 4

就我个人而言，我认为很难遵守这些类型的要求（即，有时你真的需要一个超过 20 行的方法），但本着你的问题的精神，我会提到一篇名为Object的文章中使用的一些指导方针健美操（如果您有兴趣，请参阅Thoughtworks Anthology的一部分）。

• 每种方法的缩进级别 (<2)
• 每行的“点”数（<2）
• 每类的行数（<50）
• 每个包的类数（<10）
• 每个类的实例方差数 (<3)

他还主张不要使用“else”关键字，也不要使用任何 getter 或 setter，但我认为这有点过火了。

Answer 5

OO Metrics 对我来说有点像一个宠物项目（这是我硕士论文的主题）。所以是的，我正在使用这些，我使用自己的工具。

多年来，Mark Lorenz 的《面向对象的软件度量》一书是 OO 度量的最佳资源。但是最近我看到了更多的资源。

不幸的是，我还有其他截止日期，所以没有时间使用该工具。但最终我会添加新的指标（和新的语言结构）。

更新 我们现在正在使用该工具来检测源中可能存在的问题。我们添加的几个指标（并非都是纯 OO）：

• 断言的使用
• 魔术常数的使用
• 评论的使用，与方法的复杂性有关
• 语句嵌套级别
• 类依赖
• 一个类中的公共字段数
• 被覆盖方法的相对数量
• goto 语句的使用

还有更多。我们保留那些能够很好地反映代码中的痛点的那些。因此，如果这些问题得到纠正，我们会有直接的反馈。

Answer 6

硬数字并不适用于所有解决方案。有些解决方案比其他解决方案更复杂。我会从这些作为你的指导方针开始，看看你的项目最终会在哪里结束。

但是，具体就这些数字而言，这些数字似乎很高。我通常会发现我通常拥有的特定编码风格：

• 每个方法不超过 3 个参数
• 每个方法签名约 5-10 行
• 不超过3级继承

这并不是说我从不复习这些一般性，但我通常会在这样做时更多地考虑代码，因为大多数时候我可以将事情分解。

Answer 7

正如其他人所说，保持严格的标准将很困难。我认为这些指标最有价值的用途之一是观察它们如何随着应用程序的发展而变化。这有助于让您了解在添加功能时完成必要的重构方面做得有多好，并有助于防止造成大混乱:)