Spring-Loaded Designs

• By Matt Stephens
• November 12, 2005

A few months back (wow, time flies when you’re blogging) I reviewed Pro Spring (Harrop & Machacek, Apress), an excellent book for any Java programmer exploring the open source Spring framework. I’m currently "pg-dn"ing my way through Matt Raible’s Spring Live (available as a PDF), which I’ll review in a few days’ time.

I’ve been excited and cautious about Spring in equal measure. While it represents a major step forward from the "dastardly duo", the "incorrigible combo", the… okay, okay… EJB and Struts… Spring advances the state but also introduces some problems of its own.

The main issue is that Spring encourages you to divide up all your functionality into itty-bitty little classes. Instead of just having a "BookReview" class which encapsulates all the data and behavior to do with book reviews, you end up with a BookReviewValidator, a BookReviewCommand, a BookReviewController, a BookReviewDao, a JdbcBookReviewDao, and so on. Not to mention all the unit test classes to accompany those, which more or less doubles the class count again. And each of these classes typically only contains a single short method. You end up demoting classes to the humble role of methods, losing many of the benefits of OO design.

And perhaps more importantly, you end up with domain classes that contain only data, without any behavior, because the behavior has been siphoned off into all of these other, itty-bitty little one-method helper classes. This really throws OO design principles out of an 18th-storey window. (I had to simulate this by throwing my design principles out of a 2nd-storey window 9 times, but the effect was pretty much as I'd imagined).

Luckily, the problems are not insurmountable, as Spring’s design is so darned flexible. You just have to be aware of them, and make the extra effort not to fall into the "functional decomposition" trap. For example, if you’re submitting a book review form, it’s possible to use the BookReview domain class as the command class. With a little extra effort, it could even be the Controller; and access to services such as data access could at least be routed through the BookReview, making it the central point of access for all things to do with book reviews.

Anyone who’s read Rebecca Wirfs-Brock’s excellent book Object Design: Roles, Responsibilities and Collaborations (or her classic earlier work, Designing Object-Oriented Software) will be familiar with the concepts I’m describing here, as being central to responsibility-driven design.

It says a lot for Spring’s design that you can essentially "go against the grain" and use it in ways that its creators probably didn’t intend, with an eye toward improving your application’s design. Try doing that with EJB.

(Bootnote and first of probably many shameless plugs for upcoming book: One of the reasons this matters so much to me is that I’m using Spring for the central example in my next book, Use Case Driven Object Modeling – Theory and Practice [Addison-Wesley, with Doug Rosenberg], due early next year. One of the book's burning issues is how to get from use cases to Spring/Java source code without falling into the "itty-bitty helper objects" trap along the way).