Code Metrics – Depth of Inheritance (DIT)
SKU: Premium, Ultimate
Versions: 2008, 2010
Code: vstipTool0132
Continuing our examination of code metrics (see vstipTool0129, “Calculating Metrics”), it’s time to take a look at one of the metrics designed specifically for object-oriented analysis: Depth of Inheritance. Depth of inheritance, also called depth of inheritance tree (DIT), is defined as “the maximum length from the node to the root of the tree” [CK]. We can see this with a simple example. Create a new Class Library project and, before writing any code, calculate the code metrics by going to Analyze | Calculate Code Metrics for Solution:
Since all classes inherit from System.Object, the depth is 1 currently. If we inherit from this class and examine the new class we can see the result:
Notice the lower the node in the tree (Class2 in this case) the higher the depth of inheritance. We could continue to create children and cause the depth to increase as much as we want.
Assumptions
Depth of inheritance is predicated on three fundamental assumptions [CK]:
1. The deeper a class in the hierarchy, the greater the number of methods it will probably inherit which makes it harder to predict its behavior.
2. Deeper trees involve greater design complexity since more classes and methods are involved.
3. Deeper classes in the tree have a greater potential for reusing inherited methods.
Assumptions 1 and 2 tell us that having a higher number for depth is bad. If that is where it ended we would be in good shape; however assumption 3 indicates that a higher number for depth is good for potential code reuse.
Analysis
Here is how you read the depth metric:
Low number for depth
A low number for depth implies less complexity but also the possibility of less code reuse through inheritance.
High number for depth
A high number for depth implies more potential for code reuse through inheritance but also higher complexity with a higher probability of errors in the code.
Code Analysis
When using code analysis, the Extended Design Guideline rule set contains a maintainability area:
Inside the maintainability area is a rule for inheritance:
This rule issues a warning when the depth of inheritance reaches 6 or greater so it is a good thing to have to keep you from having excessive inheritance. You can learn more about the rule here:
https://msdn.microsoft.com/en-us/library/ms182213.aspx
Putting It All Together
High values for DIT mean the potential for errors is also high, low values reduce the potential for errors. High values for DIT indicate a greater potential for code reuse through inheritance, low values suggest less code reuse though inheritance to leverage. Due to lack of sufficient data, there is no currently accepted standard for DIT values. Even studies done recently did not find sufficient data to determine a viable number that could be used as an standard number for this metric [Shatnawi]. ]. Although there is no empirical evidence that I could find to support it, several articles suggest that a DIT around 5 or 6 should be an upper limit (https://www.vitalygorn.com/blog/post/2007/11/08/Code-Metrics-in-Visual-Studio-2008.aspx , https://www.devx.com/architect/Article/45611).
Citations
[CK]
Chidamber, S. R. & Kemerer, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, Vol. 20, No. 6). Retrieved May 14, 2011, from the University of Pittsburgh web site: https://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf
[Krishnan]
Subramanyam, R. & Krishnan, M. S. (2003). Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implications for Software Defects (IEEE Transactions on Software Engineering, Vol. 29, No. 4). Retrieved May 14, 2011, from University of Massachusetts Dartmouth web site https://moosehead.cis.umassd.edu/cis580/readings/OO_Design_Complexity_Metrics.pdf
[Shatnawi]
Shatnawi, R. (2010). A Quantitative Investigation of the Acceptable Risk Levels of Object-Oriented Metrics in Open-Source Systems (IEEE Transactions on Software Engineering, Vol. 36, No. 2).