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.
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.
7 Responses to “JAR Design over Class Design”
Leave a Reply
[...] reason for this is that more teams spend time designing class relationships than anything else. Anecdotal evidence has shown this to be true. But this is not the only reason. Another surrounds their perceived [...]
[...] Generally speaking, cycles are always bad! But some cycles are worse than others. Cycles among classes are tolerable, assuming they don’t cause cycles among the packages or JAR files containing them (ie. the classes must be in the same package, essentially encapsulating the design). Cycles among packages may also be tolerable, assuming they don’t cause cycles among the JAR files containing them (again, packages are in the same JAR file). Most important is that we are aware of the relationships existing between the JAR files. In so many cases, we aren’t. [...]
[...] while back, I posted about Jar Design over Class Design, which summarizes the responses I’ve gotten over the years when asking developers where they [...]
[...] Since most principles and patterns emphasize logical design, it’s no surprise that the majority of developers spend their time dealing ony with logical design issues. Other examples of logical design include deciding if a class should be a Singleton, determining if [...]
[...] Like last year, in my Agile Architecture - Technologies and Patterns session at SpringOne2GX, I asked the attendees the same three questions surrounding class, package, and module design. This year, I had roughly 80 folks attend the session, and here is the rough breakdown of the hands shown after each of the questions. [...]
[...] design. Since most principles and patterns emphasize class design, it’s no surprise that the majority of developers spend their time dealing ony with logical design issues. Other examples of class design include deciding if a class should be a Singleton, determining if [...]
[...] corresponds as needed to the physical design, an often overlooked abstraction. Kirk’s blog post on the topic describes this issue better than I could, so I refer you [...]