Code Metrics – Depth of Inheritance (DIT)

  • Article

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:

image

 

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:

image

 

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:

image

 

Inside the maintainability area is a rule for inheritance:

image

 

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).