Design Patterns Pros & Cons

Well I guess the Gang of Four (GoF) design patterns (or Gamma's design patterns as many like to call it) are probably the most renown set of patterns available (and used) in software engineering (if you want a good explanation of what a design pattern is please refer to http://en.wikipedia.org/wiki/Design_pattern_(computer_science), to the book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al or do a search for 'design patterns' you can't miss it!J). We've all read many articles or heard a lot of stuff in regards to the pros & cons of using design patterns, and although anyone who knows me professionally would agree that I'm a pro-design pattern kind of person, I do believe that the issues raised against design patterns are extremely interesting and enlightening.

A lot of articles I've read that try to undermine design patterns usefulness, although they are a bit unfair, do have some valid points. One of these points that I found very interesting was the fact that many believe that design patterns are taking us back to a pre-reuse era where everything had to be re-coded. The argument looks valid when you look at design patterns from a distance: design patterns are ultimately providing you a solution and a couple of examples, you have to understand (or misunderstandJ) the solution and using the examples as help try to implement it, and solve your own problem.

On closer examination, especially if you have used design patterns in real life, you realize that design patterns are supposed to provide you with a different type of reuse. A type of reuse that I would like to call "concept reuse" or "idea reuse." Design patterns try to provide a structured way of thinking and organizing a solution so that people with less experience with that domain or problem can soak up the experience of the more adept designer/developer and hopefully save a whole lot of time, agony and trial & error in the process. That being said we can't ignore the fact that design patterns in their purest form will not give you a ".dll" or ".class" or any other similar re-usable binary code that you can plug into your program and start using it. But the point behind design patterns is that if they did provide that kind of plugable/reusable solution we would have not had the whole idea/concept type of reuse. Let's delve into this a bit further:

Software reuse has been a major driving force behind a lot of innovations in the industry. From the very early days of software development reusing a piece of code has been the "second priority" of many projects (hopefully the "main priority" has been delivering to customer requirements). So why shouldn't design patterns be a step forward in the same evolutionary process? As I mentioned above I believe design patterns are another form of reuse which is different from binary code or source code reuse. Yes we can develop a series of components, frameworks and even code generators to ease the implementation process of design patterns [see http://se.ethz.ch/~meyer/publications/computer/visitor.pdf] but that still will not fill in the function of design patterns. At a higher level than components, binary code, etc. etc. there exist concepts and ideas and solutions in which if we have a uniform way of describing them we can communicate faster and more efficiently in a team. When we use design patterns we can document & evaluate an implementation a lot easier than actually describing everything in detail. We can compare and discuss two competing designs based on the merits of each one and finally pick a good "design pattern" to shape our solution. Design Patterns are a method to encapsulate "expertise."

I would like to add that for design patterns to be really helpful as "expertise encapsulations" your team members should all be intimately familiar with them and this sometimes can be a big downside to extensively using them in a project. Obviously if some members of your team are design pattern experts and the rest of them think design patterns pertain to fashion than you basically have two groups in your team each trying to talk in completely different languages and well we all know what happens next.

I would also like to add that sometimes extensive use of design patterns is overkill. Some problems, especially if the requirements and future change is very predictable and stable, can be solved very easily without employing design patterns. It's also fair to say that once a developer/designer is fluent in the use of design patterns he/she can incorporate them into a solution as easily as using any other design construct. But this doesn't mean that the next guy who comes along and is going to maintain that project or make some changes to it has the same intimacy with design patterns as the first designer therefore we have another overkill. To sum up, design patterns should be used wisely and where needed and like any other tool that we have at our disposal if you try to fix everything using design patterns you're going to end up in a big mess.

So the next post I'll do on design patterns would be a fresh look at probably the most famous design pattern of all time (and probably the simplest): Singleton. Now I know it sounds kind of cheesy to be writing about the same thing as everyone else has already done a million times but I believe that I have some very interesting experiences and fresh ideas regarding this very simple (and useful) pattern to share with everyone. Plus it will give everyone an idea on the level of detail I'm going to get into once I start writing about the other GoF design patterns.