John Wood

Source Code Metrics Pt 4: Coupling

To wrap up my adventure into complexity analysis I'm going to cover something called "coupling" of code. In a world of extreme programming and service orientation, the trend is to write loosely coupled components that can be easily re-used in future applications with minimal changes. Coupling is really the easiest way for us to determine the re-usability of a class, and the good design of an application.

As part of my build I want to see just how re-usable the code in my project actually is, and I want to see whether a specific change or new feature in the project has somehow affected the overall re-usability of the project.

So what constitutes coupling? Quite a lot of research has been done in this area, especially by Chidamber and Kamerer who devised an index known as "CBO" or "Coupling Between Objects".

The gist of the research is this: Whenever we reference another class in our component's implementation, we're tying ourselves to that class. A reference includes both property accesses and method calls. This means that if we want to use that component later on, we'd have to make sure those dependencies were also available and this complicates our ability to re-use that component.

This can't be said of method calls to interfaces though. Calling a method on an interface instance does not constitute coupling, because the implementation of that interface can easily be replaced, so you're no longer bound to the specific class and can implement the interface yourself making re-use a possibility.

You can read more about Chidamber and Kamerer's work here http://www.pitt.edu/~ckemerer/clnieee.pdf.

Based on my understanding of this metric, I've enhanced my CCMetrics command-line utility so that it now also reports on the coupling of methods and classes. In this case, the coupling index is calculated based on the number of unique classes referenced that are not interfaces. The unique references are counted at the method level as well as the class level. The most-coupled class is reported in the summary, and individual method couplings can be seen in the XML output.

You can test this utility by downloading it here.  Let me know if you find any problems.