Too many dependencies to manage?

Kirk Knoernschild (who has created an interesting utility called JarAnalyzer that identifies dependencies among jar files) questioned how it could be possible to manage all the dependencies at lower-than-jar (like package) levels – aren’t there just too many dependencies?  Nah…

All dependencies, at any level, roll up from specific lines of code. And yes, if you take a flat view of the world, there are an impossible number of dependencies to control.

However if you use the package hierarchy not just as an extension of the file-system, but as a “design” (or whatever term you prefer, I like “structural control”) medium, then the principle of divide-and-conquer can work as in any engineering discipline. If, at every point in the package hierarchy you have a “mind-sized-chunk” of design breakout, a scaleable design process is possible since the volume of dependencies to be controlled is drastically reduced.

For example, if we have a flat (i.e. just one level of “hierarchy”) package design, and in a development iteration Class A.B becomes newly dependent on class X.Y, this has no “design” impact if there was already a dependency from any class in package A to any class in package X.

The volume of notable design changes is further reduced dramatically if we use a hierarchical package design since a new code-level dependency is now notable only if it creates a new dependency between 2 high-level packages *.P.Q.* and *.P.R.* if none of the code in any of the subpackages of Q previously depended on any of the code in any of the subpackages of R.

Controlling this quantity of dependencies is possible if you have a way of *seeing* how the dependencies roll up through the package hierarchy and a way to automatically detect the introduction of a notable dependency (Structure101 does this, naturally).

Of course, whether you want to keep the structure as-is on a project in which it has been out of control for a long time is a whole other question… more on this later.