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.
+1
A:
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.
Dan Bryant
2010-04-17 12:45:18
It would have felt good to have an automated tool spit out a number (42?) and have it nicely correlate with the parts of the system that I had subjectively determined hadn't been written in an OO way. I guess other metrics that show the evidence of procedural programming (long, complex methods) will have to suffice as counter-examples. Thanks for both your answers.
Jono
2010-04-17 21:19:20
Yes, I do have a specific code base in mind. Added to by numerous developers over the years, it has no formal documentation (other than itself,) and exhibits many qualities that hinder understanding. As such, a tiny change takes a long time to implement (and even longer to implement correctly,) and even then might have unexpected side effects. As you've intoned, other metrics exist that are useful for identifying the problems in this code. I wanted to be able point at the non-existent metric and say "Hey! We didn't follow the basic OO design principles and _that's_ how we got into this mess."
Jono
2010-04-18 07:51:21
To analyze how easy it is to introduce side effects, I think looking at class coupling for each method would be helpful. I would also look for any global state, as that's one area that's counter to OO design principles and which is likely to introduce side effects when making changes. You might find that methods which reference global state are more likely to have had bugs.
Dan Bryant
2010-04-18 12:18:38
I guess the actual question's answer is "no" then; thanks for your comments and suggestions.
Jono
2010-04-22 14:35:18
A:
Have a look at the 82 code metrics definitions supported by the tool NDepend for .NET developers.
Patrick Smacchia - NDepend dev
2010-08-30 16:31:04