I saw a great speech at No Fluff, Just Stuff by Venkat Subramaniam on Spring and Groovy. It’s an interesting technology, but what was really interesting to me was a brief exchange near the end.

One person commented that they didn’t understand the general opposition to using constructor-based dependency injection. Venkat initially gave the standard answer that constructors became unweildly with lots of properties. Sensing that was a pretty unsatisfactory answer, he went on to say that he granted that having constructor args was better from an object theory “puritanical” point of view, he found that extending his objects became more difficult.

I’m not sure this is a legitimate argument. If you really have to have mutable state, at least try to prevent your objects from being constructed in an unusable state. In addition to the theoretical nicety of not having nonsense objects, there is a deep practical (if not pragmatic) consideration: unit tests should address all significant state categories that an object can be in. If you allow an object to be in more possible states, that means you need to write more unit tests. This is time and pretty mindless effort that your compiler could spare you from if you’d let it.

But is this issue of extension critical enough to overwhelm the advantages the compiler gives? I don’t think so. If you need to extend a class, you need to pull the constructor arguments forward — this is the required state for the object which needs to be addressed. If they need to be wrapped or translated, that can be handled through static methods. If you need to generate objects piecemeal, use the factory pattern (which Spring supports quite nicely). And, in general, composition should be favored over inheritance.

One of the other people in the conference noted that Spring now has a @Required annotation. I will address that over at another blog (here).

Popularity: 3% [?]

Well, it looks like I’m going to be doing two sessions at MinneBar: one on using Fit (a Java framework) to generate executable documentation (and how this makes life nice for business-types that have to talk to Java developers), and one as a brainstorming session on Functional Languages and Agile Development (basically so I can figure out what to do at Agile 2007 and stop feeling like the only functional coder in MN).

Edit: Looks like the customer experience architect for my current shop is going to be there, too. He’s pretty jazzed for it, and I trust his recommendation a lot.

Popularity: 3% [?]

I’ve been getting into Kettlebell training, which is a lot of fun. Think of doing a work-out based around a cannonball with a handle, where you take the cannonball and swing it around, flip it in the air, and generally do all kinds of fun stuff with it. The workouts I have been doing also involve a lot of precision work that require balance and inner focus a la yoga — although that might be at least in part because my trainer is also a yoga enthusiast.

If you’re interested and in the Twin Cities area, there’s a free, open-to-the-public introduction to kettlebells on April 29th. Here’s info about it:

Sunday, April 29 1:30 - 2:30PM
Dayton’s Bluff Recreation Center
800 Conway Street, St. Paul, 55106
Community Center ph# 651-793-3885

Contact Dennis at 651-487-2180 or email support@dragondoor.com for more info and to reserve your spot. It will be outside, so you need to dress for the weather…

And here are some videos of kettlebell workouts.

Popularity: 2% [?]

Okay, I’m making a new Best Practice Declaration.

As of Java5, you should no longer use arrays. The Arrays#asList gives you all the niceties of the inline array constructor while still allowing you to leverage an API which doesn’t suck (doubly so when you consider the Commons Collections API).

Popularity: 2% [?]

There’s a lot of buzz about Groovy right now, which makes Java look like Ruby (including a shameless Rails knockoff). One guy at work is really excited about Groovy, and has incorporated it into his open source project.

From what little I’ve seen from it, it’s got all the same advantages and disadvantages as your standard scripting languages (Perl/Python/Ruby): no safety at all (Compiler? We don’t need no stinkin’ compiler!), but it’s easy to express simple imperative instructions. It runs in the JVM and alongside your other Java code, which makes it a nice way to script your object calls, and I could easily see it taking over the main() classes — I wish I had known about Groovy back when I was on “DataDiff”, so we could have used it to provide plaintext (editable) code to respond to some of the operations-style issues.

Popularity: 2% [?]