Tag: design

Would you blame the hammer because the nail is blunt?

Cedric’s having another go at JUnit Again he misses the point: extensions to JUnit are not JUnit itself, and JUnit can’t be blamed for people extending it to the wrong way.

Continue reading “Would you blame the hammer because the nail is blunt?”

Programming by difference

I’m currently working my way through Michael Feathers Working Effectively With Legacy Code. Damn good book, BTW. Anyway, this was this section on “programming by difference” that got my thinking while reading it.

Continue reading “Programming by difference”

The Dating Game

Working with legacy code can present some, um, interesting challenges. I just hit a wonderful issue to do with dates and timezones, caused by a really piss-poor data model.

Continue reading “The Dating Game”

Never use a working template

A common feature of many IDE are templates, which greatly speed writing code. People often create their own “cut-and-paste” templates as well.

An important rule to remember here is that no template should ever “work” out of the box. This way, if (for whatever reason!) you don’t fill it in, you know it will fail fast. This helps avoid bugs that can be quite subtle: template code which fails slowly. 🙂
Continue reading “Never use a working template”

Expressing Intent vs Duplication

I had an interesting conversation with a colleague this afternoon. It centred around what was more important: expressing intent (which I was advocating) vs. removing duplication.
Continue reading “Expressing Intent vs Duplication”

Hibernate named queries rock

I’m now working on my second project with Hibernate, having delivered the first, and I’m playing with some of the features I didn’t have time to figure out last time. And I have to say: named queries rock, big time.

Continue reading “Hibernate named queries rock”

Creational vs access patterns, and other diversions

A little while back, I blogged about how static and singleton are not synonymous, and one of the things I mentioned in there was the concept of an “access pattern”. This is a term I’ve been kicking around for a while (in person, anyway… I think that was the first time I’d written about it), and I wanted to explore it a bit more here.
Continue reading “Creational vs access patterns, and other diversions”

Singleton != Static

On Cedric’s latest entry he complains about statics, and quite rightly. However, one of the commentators missed the point.

Continue reading “Singleton != Static”

“Pass-the-parcel” exceptions.

Hani makes a surprisingly unbilish point about wrapped exceptions Wrapping already wrapped exceptions isn’t the best idea in the world.

This technique reminds me of the children’s game of “Pass the Parcel”, where you put multiple layers of wrapping on a gift, and the children never know when they will reach the last one.

I’m as guilty of this as the next person, but I think in future I will modify the constructors of my wrapping exceptions so that if a cause already exists, it uses that as the cause, not the one supplied…

(FWIW, I’m not against wrapping exceptions; what is an ObjectNotFound at one layer is a ConfigurationException at another, and should be reflected as such).

This may, of course, just be a stupid idea, but it’s worth exploring.

Don’t Overcomplicate Things

A gentle reminder to myself: don’t make things more complicated than they need to be.

Continue reading “Don’t Overcomplicate Things”