Many of us spend time designing class relationships. In fact, a significant benefit of TDD (Test Driven Development) is the positive influence it has on design. A few years back, the Martin Metrics sparked interest in managing higher level dependencies, explaining their importance, and giving birth to JDepend, and other static analysis utilities such as JarAnalyzer. Yet, an important higher-level unit of deployment has been largely ignored…the .jar file.

Brief History - Why Package Design


The Martin Metrics are based upon important design principles. For large software systems, these principles help bring order to the organization of your system, and offer guidance in helping you allocate classes to their appropriate packages. Even the most flexible class structure will not yield high degrees of resiliency if not allocated to a well-designed package structure. Managing package dependencies makes good design sense because the package structure offers a higher-level view of your system. For instance, if package A has no incoming dependencies (and more importantly, you actually know it has no incoming dependencies), you can be certain that changing any class within package A will not have a negative impact on other areas of the application. Tools such as JDepend help enforce, and inform you of, package relationships. Understanding package dependencies increases testability and makes maintenance easier.

Next up – Jar Files


If giving proper thought to how classes are allocated to packages is important, then giving proper thought when allocating classes and packages to .jar files is also wise. In fact, for large software systems, I contend that the Martin Metrics and supporting principles are more valuable when applied to .jar files than to packages. Since the metrics and principles emphasize the unit of deployment and the granule of release, this makes sense. Fewer physical dependencies among .jar files results in more reusable, maintainable, testable, and extensible software.