The Use and Misuse of Design Patterns

Design Patterns have always been of great interest to me.  (If you doubt this, you can see that I have a section of my Bookshelf dedicated to the topic.)  One of the greatest advantages to learning the basic patterns is to share a common language with your fellow developers, so when you talk about a Factory Method or Decorator, I know what you are talking about.  But at the same time, I see a tendency for some developers to use patterns for the sake of using patterns without fully considering the benefits and costs.

Rocky Lhotka has a great article about what developers should think about when considering patterns in their projects.  You can find it here: On the use and misuse of patterns.  Go take a look at it now.  Don't worry; I'll wait.

Okay, are you done reading it?  Go back and read it again.  It's that important.

Welcome back.  I've experienced a few of the issues that Rocky mentions.  First, I have seen the "Pattern of the Year" phenomenon.  It seems like some of the developers in my group get stuck on the current popular pattern.  I won't mention any specifics, because as Rocky notes, there's nothing wrong with the pattern itself.  The problem is that the popularity leads to a sort of cult of people who feel like they need to implement the pattern whether it fits in with the application or not.

Second, I have seen developers that get so enamored with a particular pattern than they try to use it at every turn.  Rocky's analogy is great on this:

"It is kind of like a carpenter who spends a lot of money buying some really nice new power tool.  And then trying to use that power tool for every part of the construction process -- even if that means being less efficient or increasing the complexity of the job -- just to use the tool."

Design patterns are just tools.  Part of being a good developer is understanding the strengths and weaknesses of each of those tools.  As developers, we need to focus on the problem space that we are working on and pick the appropriate tools for that job.  (As a side note, this extends beyond design patterns to the technologies that we use -- whether WPF, Silverlight, or WebForms -- and even further out to the platform -- whether .NET, LAMP, Java, or whatever.)

I do have an issue that I'm not quite sure how to approach: I have worked with a developer and talked about the benefits and costs of a specific design pattern.  We both agreed on the strengths (what the pattern was trying to solve for) and the weaknesses (the added complexity).  And we also agreed that we would not get the benefits of the pattern in the current application we were discussing.  The frustration is that the other developer still wanted to use the pattern because "we might need it later."  Experience shows that this would be unlikely.

So, if you have any suggestions on how to approach this type of situation, let me know.  I'll be sure to share the good responses here.  Send them to feeback@jeremybytes.com.

If you are new to the design patterns world, I would encourage you to learn the benefits and costs of each pattern.  And above all, consider their usage carefully.  Patterns are a wonderful tool.  But don't get so wrapped up in the tool that you forget the problem you are trying to solve.

Before you go, go back and read Rocky's article one more time: On the use and misuse of patterns.

Happy Coding!