JAR Design Over Class Design

In early December, I spoke at SpringOne Americas and delivered a session on OSGi. Whenever I speak about application design or architecture, I always ask the audience three questions at the beginning of the session. In this session, I had about 40 or 50 folks in attendance, and here’s a rough breakdown of the hands shown after each of the questions.

• How many spend time designing classes, both the behavior of a class and the relationships between classes? Almost everyone raised their hands.
• How many spend time designing packages, both the behavior of a package and the relationship between packages? Only about 5 hands went up.
• How many spend time designing JAR files, both the behavior of a JAR and the relationship between JAR files? Only about 2 or 3 hands went up.

These are common responses. Most development teams spend time designing classes, but few spend time designing JAR files. That’s unfortunate, because failing to design JAR files inhibits reusability and hinders maintenance. Even the most flexible class design is severely compromised if all classes are packaged and bundled into the same module.

When designing software systems, more effort should be devoted to designing the granularity of JAR files and managing the relationships between JAR files. When designing classes, more effort should be devoted to designing classes whose relationships
span JAR files, with less effort devoted to classes whose relationships
are encapsulated within a JAR file. Why? Classes whose relationships are encapsulated within a JAR file are isolated from the rest of the application, and can be more easily refactored because the ripple effect of change is constrained to the JAR file. Packages, as the intermediary logical concept, are important in helping bring greater internal design resiliency to a JAR file.

And, of course, design is a evolutionary activity involving many tasks, including a combination of modeling, coding, and testing.

From http://techdistrict.kirkk.com/