【问题标题】:Metric to measure object-orientedness衡量面向对象性的指标
【发布时间】:2010-04-17 11:11:14
【问题描述】:

是否有一个指标可以帮助确定系统或应用程序的面向对象性?我在 .NET Reflector Add-ins codeplex 项目中看到了一些非常简洁的指标,但还没有这样的指标。如果不存在这样的指标,它甚至可能或有用吗?面向对象编程有 3 个假定的原则:封装、继承和多态;根据这些对程序进行排名的工具可能能够显示 C#(或类似)代码库中放弃了整个面向对象的理想的区域,以及与该区域与项目的其余部分相关联的错误数量。

【问题讨论】:

  • 这取决于您是否认为使用继承自动是一件好事 - 根据我的经验,大多数开发人员使用它非常糟糕。
  • 我正在寻找一个客观的衡量标准,看看这些原则是否得到了应用,此时我可以开始对其有效性得出结论。我想关于开发人员如何错误地使用语言或范式特性的轶事证据将成为社区 wiki 问题的范围,我现在正试图避免。
  • 有类耦合和继承深度的度量,分别是封装和复杂度的粗略衡量。它们不是衡量模式是否为“OO”的具体衡量标准,而是衡量您需要一次理解多少代码才能理解给定类的衡量标准。

标签: .net oop code-metrics


【解决方案1】:

对好的 OO 设计的一个有意义的解释是,设计中的对象在逻辑上和一致地映射到正在建模的域对象。解释这一点需要深入了解您要解决的问题,包括整体背景。自动化指标还不够复杂,无法以这种方式理解上下文。


为了回应评论,我想我会扩大一点:

我希望提出的主要观点是 OO 不是“封装、继承和多态”。这些只是能够将问题建模为以明确定义的方式交互的对象的工具。如果您想要一个好的指标,您需要了解您真正想要衡量的内容。听起来您正在尝试使用度量来验证代码质量的“直觉”概念以支持这种感觉。如果是这样,真正的潜在担忧是什么?您是否担心代码很脆弱并且可能由于意外的副作用而容易损坏?对象模型是否过于分散且难以遵循?单个对象是否太大而无法理解和维护?如果您可以更好地定义您希望识别的缺陷类型,它将帮助您找到合适的指标。如果他们有帮助,这里是一个useful set of metrics

【讨论】:

  • 如果有一个自动化工具能吐出一个数字(42?)并让它与我主观确定的系统部分没有写在 OO方法。我想其他显示程序编程证据的指标(长而复杂的方法)将足以作为反例。感谢您的回答。
  • 是的,我确实有一个特定的代码库。多年来被众多开发人员添加,它没有正式的文档(除了它本身),并且表现出许多阻碍理解的品质。因此,一个微小的更改需要很长时间才能实施(甚至更长时间才能正确实施),即便如此也可能会产生意想不到的副作用。正如您所言,存在有助于识别此代码中的问题的其他指标。我希望能够指出不存在的指标并说“嘿!我们没有遵循基本的 OO 设计原则,这就是我们陷入困境的原因。”
  • 为了分析引入副作用的难易程度,我认为查看每种方法的类耦合会有所帮助。我还会寻找任何全局状态,因为这是一个与 OO 设计原则背道而驰的领域,并且在进行更改时可能会引入副作用。您可能会发现引用全局状态的方法更有可能出现错误。
  • 我猜实际问题的答案是“否”;感谢您的 cmets 和建议。
【解决方案2】:

查看 NDepend for .NET 开发人员工具支持的 82 个code metrics 定义。

【讨论】:

    猜你喜欢
    • 2014-05-07
    • 2011-10-01
    • 2011-02-11
    • 1970-01-01
    • 2011-12-19
    • 1970-01-01
    • 1970-01-01
    • 2017-09-14
    • 1970-01-01
    相关资源
    最近更新 更多