Keith Donald reports that Spring’s architecture contains not a single dependency cycle. I’ve looked at the structure of many open source projects and generally found them riddled with dependency tangles (junit is an exception – perhaps unsurprising given its small size). So I loaded Spring into structure101 (structure101.com) for a closer look. And sure enough, no package-level tangles dispite it’s reasonable size of about 70KLOC (estimated from bytecode) divided into 139 packages.
I was half expecting to find tangles introduced at the meta-package level since often only dependencies between leaf packages (i.e. the ones that contain classes) are monitored. But no tangles here either.
So then I looked for any package-level over-complexity. Just one package comes on the radar – package org.springframework contains 95 inter-package dependencies:
To me this is a bit on the complex side – we usually recommend keeping the complexity of packages to 60 dependencies, so personally I would divide this package into 2 more-or-less equal sized ones for a "perfect" package structure.
Finally I took a look at the complexity of the code below the package level. The rationale here is that it’s no good having a simple, acyclic package structure if the packages contain excessively complex classes or methods – this just moves a complexity problem to a different place. Here I did find some over-complexity – this is an exerpt from the strucure101 summary report, with the class complexity threshold set to 120 (inter-method dependencies) and the method complexity (cyclomatic) set to 15:
Fat (class): Top 5 (of 7)
Fat (method): Top 5 (of 26)
|org.springframework.jdbc.core.SingleColumnRowMapper.getColumnValue(ResultSet, int, Class):Object||38|
|org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.createCustomException(String, String, SQLException, Class):DataAccessException||37|
(Again, the amount of over-complexity ("Fat")at these levels is way less than would be usual for projects of this size).
Refactoring to remove the over-complexity for these items will most likely have a ripple effect. Some other packages may now become overly-complex and will necessitate adjustment to the package design. But once completed, the structure would be fully balanced and to my mind "perfect".
Serious credit to the Spring guys for building possibly the best structured code-base in the world!(Other than the Structure101 code-base of course :-)). Now, a question to the Spring developers and users – what benefits do you get from this great structure?