衡量面向对象的指标
是否有一个指标可以帮助确定系统或应用程序的面向对象性？我在 .NET Reflector Add-ins codeplex 项目中看到了一些非常简洁的指标，但还没有类似的指标。如果这样的指标不存在，它是否可能或有用？面向对象编程有 3 个假设的原则：封装、继承和多态性；根据这些对程序进行排名的工具可能能够显示 C#（或类似）代码库中放弃整个面向对象理想的区域，以及可能有多少错误与该区域相对于项目的其余部分相关。
Is there a metric that can assist in determining the object-orientedness of a system or application? I've seen some pretty neat metrics in the .NET Reflector Add-ins codeplex project, but nothing like this yet. If such a metric doesn't exist, would it even be possible or useful? There are the 3 supposed tenets of object-oriented programming: encapsulation, inheritance, and polymorphism; a tool that ranked programs against these might be able to show areas of a C# (or similar) code base where the whole object-oriented ideal was discarded, and perhaps how many bugs are associated with that area versus the rest of the project.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
良好的 OO 设计的一种有意义的解释是设计中的对象在逻辑上一致地映射到正在建模的域对象。解释这一点需要深入了解您要解决的问题，包括整体背景。自动化指标还不够复杂，无法以这种方式理解上下文。
为了回应这个评论，我想我应该扩展一下：
我希望表达的主要观点是，OO 不是“封装、继承和多态性”。这些只是能够将问题建模为以明确定义的方式交互的对象的工具。如果您想要一个好的指标，您需要了解您真正想要衡量的是什么。听起来您正在尝试用一个指标来验证代码质量的“直觉”概念来支持这种感觉。如果是这样的话，真正的根本问题是什么？您是否担心代码很脆弱并且可能由于意外的副作用而容易损坏？对象模型是否过于分散且难以遵循？单个对象是否太大而难以理解和维护？如果您可以更好地定义您希望识别的缺陷类型，它将帮助您找到合适的指标。如果它们有帮助，这里有一个有用的一组指标。
One meaningful interpretation of a good OO design is that objects in a design map logically and consistently to the domain objects being modeled. Interpreting this requires a deep knowledge of the problem you're trying to solve, including the overall context. Automated metrics are not yet sophisticated enough to understand context in this way.
In response to the comment, I thought I would expand a bit:
The main point I was hoping to make is that OO is not 'encapsulation, inheritance and polymorphism'. Those are just tools that enable modeling of a problem as objects that interact in well-defined ways. If you want a good metric, you need to understand what you're really trying to measure. It sounds like you're trying to validate a 'gut feel' notion of code quality with a metric to back up the feeling. If that's the case, what's the real underlying concern? Are you worried the code is brittle and likely to break easily due to unexpected side effects? Is the object model too fragmented and hard to follow? Are the individual objects too large to understand and maintain? If you can define better the kinds of flaws you're hoping to to identify, it will help you to find appropriate metrics. In case they are helpful, here is one useful set of metrics.
查看 .NET 开发人员工具 NDepend 支持的 82 个代码指标定义。
Have a look at the 82 code metrics definitions supported by the tool NDepend for .NET developers.