Question on Module Design
Join the DZone community and get the full member experience.Join For Free
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.
- How many spend time designing classes, both the behavior of a class and the relationships between classes? About 80% of attendees raised their hands.
- How many spend time designing packages, both the behavior of a package and the relationship between packages? Roughly 20% raised their hands.
- How many spend time designing JAR files, both the behavior of a JAR and the relationship between JAR files? Again, about 20% raised their hands.
These are consistent responses to what I see elsewhere, as well. I was hopeful that since I was attending the Spring conference, a few more developers were leveraging OSGi and actually spending some time on module design. But that doesn’t look to be the case. Maybe modularity isn’t sexy enough? I suppose that’s just a bit more fodder for the argument that there is no migration path for modularity, and that we need better tools, tutorials, and educational materials to help us design modular software. Fact is, I had more than one person stop to ask me where they can find more information. And that’s why recently, I’ve been focusing my talks on what we can do today, right now, to design more modular software.
I know we’ll be there someday. After my OOPSLA tutorial this week, Alex Buckley stopped by and we chatted for a while on modularity in JDK 7. Whether it’s Jigsaw, OSGi, or both, we can’t be sure. But one thing is certain - modularity is coming to the Java platform, and while it might not be all that cool and exciting right now, it’s going to play a significant role in how we architect and design applications going forward.
Opinions expressed by DZone contributors are their own.