Evil Design Patterns - When Design Patterns Become the Problem

When Design Patterns Are Evil

Have you ever been on a project in which all of your team members have just gone through an intense week of design pattern training? It's painful, as the project ends up becoming some type of sadistic competition where every line of code must be implementing a pattern out of the Gang of Four (GoF) book."Hey, this needs to be redesigned a fly-weight" or "Hey, this needs to be re-done as a bridge." The next thing you know, a simple application is needlessly polluted with superfluous code that does little more than demonstrate the author's ability to implement a 'chain of responsibility' or a 'composite bridge.'

Whenever I see a team getting a little overly ambitious with the content of the GoF book, I always like to send out an e-mail, or update the project Wiki, and point the team to Paul Wheaton's article entitled "Evil Design Patterns." The article is short, the article is concise, and even more to my liking, it's a little bit snide. But it also contains some pertinent advice.

"Patterns started off as generally recognized solutions for common problems." The article says. "But now they've been around for a while and we have experienced applications being made ten times more complicated than they need to be because people try to cram in all they patterns that they have read about."

I got a chance to talk to Paul about the four year old article the other day, and while the article was written a while ago, Paul still thinks the message is pertinent. "I wrote this as a way of protesting. I wrote this because I really believed that patterns were going into a messed up space. Patterns are important. But keeping things simple is important as well." And this pretty much reiterates the article's assertion that "any pattern being used in an application could/should(/must!) be trumped by 'the simplest thing that could possibly work.'"

I mentioned to Paul that the article had been reprinted in the back of the Head First Design Patterns book, indicating that his views obviously reflect a shared sentiment, even by avid proponents of using patterns.

"Yeah, when they (Eric T Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra) started writing Head First Design Patterns, which we were incubating on JavaRanch, I sent this to them and said 'this has to be at the beginning of the book.' When the book finally came out, it was at the very end."

Paul sounded a little dejected about the fact that his blowhard rant against Design Patterns wasn't turned into the forward. I do agree with the book's authors however, as starting off a book on Design Patterns by telling the reader how disastrous it can be to use them, probably isn't the type of motivation people need when learning what can be a bit of a dry subject.

So, what is the big value we get from using design patterns nowadays? "I now think that the primary purpose of patterns is to expand our vocabulary. I can say 'singleton' and we all know what that means. I can say 'front controller' and we all know what it means."

Anyway, the point is not to completely disparage "Design Patterns." Our most popular frameworks and specifications, be it Spring, Hibernate or GWT, are filled with them. The point is that there needs to be balance; and if the design pattern zealots on your team start getting a little bit out of control, don't be afraid to send them the link.

Evil Design Patterns, by Paul Wheaton
Head First Design Patterns
Design Patterns, Gang of Four (GoF)

Paul Wheaton is the miserable-evil-tyrant owner of JavaRanch. He's also a little obsessed with permaculture, although, on the good side, his obsession has translated into some good advice on organic lawn care.