engineering

I've been reading up on design patterns lately, particularly those in Core J2EE Patterns. Design patterns are great - they help software architects rely on the collective knowledge and experience gathered from past projects; they also allow designers, developers, and analysts to use a common language.

It occurred to me while flipping through the Core J2EE Patterns that several of them are either outdated or at least their utility has been diminished by advances in JavaEE. (Not to mention that this may mean some of the Core J2EE 'patterns' are too implementation specific and may be better labeled as strategy than pattern).

After seeing a pretty funny blog entry last week on Dart-board Driven Design, I thought I'd finish off a blog post I started on deciding when to use design patterns.

My argument is that the cost of the additional layer of 'pattern' code should be outweighed by the  value the pattern delivers; further, you must evaluate the value when implementing any pattern.

Sometimes I look at old draft blog entries and ask myself “what was I thinking?”. Every once in a while, though, I look at an old draft post and say “hey, that’s pretty cool!”. This article fell into the pretty cool category, not so much for the content, but the example app, so I hope you enjoy it (OK, you can skip to the end now).