A colleague of mine introduced me to the Design By Contract implementation done for Spring called SpringContracts. It’s gotten me looking at it for the last couple days. It’s most definitely an interesting concept, so I brought it up to the rest of the guys at work to find out what they thought.

The biggest concerns were:

1) Binds you to Spring (if you use SpringContacts):

No big deal here. We’re already fully invested into Spring.  Either way, I don’t beleive in complete de-coupling of technology. If you’re using a technology and investing time and man-power into it, you had better make the most of it. I reject the idea that putting Spring specific annotations in your code is bad practice (in my current environment at least)

2) Need to learn a new technology/language

Again, I have a lot of trouble with this. Do we need to always stay at the lowest denominator just to satisfy the ones who refuse to learn? I beleive that enthousiasm for something new and teams that are willing to teach and share their knowledge don’t mind these types of additions, especially if they get something out of it. Luckily, I work with that type of team (they really are friggin great!)

There’s a good discussion about that very subject here.

3) AOP + Introspection = Lowered performance

Yup. Absolutely. If this thing puts a major hit on the performance of my code, then I’d have to re-consider. In my current environment, I can’t afford a big hit to performance. But in most places, having more solid, more self-documented, more bug free code is what you should strive for. An extra millisecond here or there won’t kill anyone. Remember: “Scalability is not your problem. Getting people to give a shit is.”

I’ll try to post some benchmarks this weekend …

4) All this to avoid a few null checks

EXACTLY! If I can enforce the semantics of every class that implements an interface, then I don’t need to check for those nulls and those illegal arguments. Ever. How many times do you just do that check … just in case a new implementation doesn’t do what you expect it to. With an annotated interface defining and enforcing the state of a returned object, you have cleaner and more readable code.

What’s important here is that Design By Contract isn’t just about fancy assertions. It’s a way to enforce the semantics of an implementing class.

That being said, all the Java implementations of DBC libraries have been inactive forever. That makes me think that it may have turned out to be a big shinny and temporary toy. I’d be curious to know if anyone has used this. I’m still on the fence, but the concept is definitely winner.

(Something to read)