My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox

EclipseCon

March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture

Catalyst

July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response (http://t.co/KrN8XNWg) to the @mreinhold #jigsaw announcement (http://t.co/9YvcDdqC). 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. http://t.co/9YvcDdqC. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

JAR Design over Class Design

Filed Under Architecture & Design, Development, Java, OSGi |  

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.

Comments

8 Responses to “JAR Design over Class Design”

  1. On SOLID Principles & Modularity : Software & Technology @kirkk.com on February 25th, 2009 5:44 pm

    [...] 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 [...]

  2. Software Rot - Manage those Dependencies : Software & Technology @kirkk.com on April 6th, 2009 3:47 pm

    [...] 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. [...]

  3. A Question on JAR Design : Software & Technology @kirkk.com on April 8th, 2009 3:00 pm

    [...] 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 [...]

  4. Modularity Patterns : Software & Technology @kirkk.com on August 5th, 2009 11:50 pm

    [...] 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 [...]

  5. Question on Module Design : Software & Technology @kirkk.com on October 30th, 2009 7:55 pm

    [...] 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. [...]

  6. Chapter 6 – Realizing Reuse : Modular Architecture on December 21st, 2009 7:12 pm

    [...] 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 [...]

  7. Mike Nash’s Two Cents Worth » Blog Archive » Why Modularity? on April 26th, 2010 2:06 pm

    [...] 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 [...]

  8. Why Modularity? - JGlobal Limited on October 17th, 2013 10:32 pm

    [...] 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 [...]

Leave a Reply