In Defence of Design Patterns

There have been some recent blogs where the GoF Design Patterns book has come under some criticism lately. As a senior manager and developer of business applications, I feel the need to weigh in on this subject.

But first, let me discuss some history to set the proper context. Writing software for complex systems is very hard and error prone, always has been, always will be. Twenty years ago, a group of computer scientists asked themselves why this was so and came up with a new way of designing software with a focus on managing complexity. This was called Object Oriented Programming.

The problem was that for all of its promises and good intentions, OOP wasn't really decreasing the probability of project failure all that much. It turns out that there are plenty of ways to design a fully OOP compliant system that was just as bad as any monolithic system.

Ten years ago, the GoF book was first published. I believe that it was published to show developers how to create OOP designs that were useful. I learned a lot from it and recommend it to any developer who has even the slightest interest in developing OOP systems. There aren't too many other ten year old software development books out that there that I would give such a blanket recommendation for, by the way.

The two biggest criticisms that I have encountered about this book can be summed up as follows. It doesn't really address the needs of unit testing and it encourages a mindless copy and paste mentality to designing systems.

With regards to unit testing, I believe that the mediator pattern would best be applied to solving this problem. That pattern is one of the original patterns from the book. If you read that pattern, then you won't find any mention of solving unit testing problems. That is because unit testing didn't really get a big emphasis until around the time of eXtreme Programming which came after design patterns. Software engineering is still very much in its infancy and we still have a lot to learn about writing complex systems with minimal risk. Modern IoC systems, like spring, make it easy to write unit tests for n-tier systems because they promote loose coupling which makes it just as easy for a middle tier application to be called from a web server as it is to be called from a JUnit test program. Loose coupling is what the mediator pattern is all about.

With regards to copy and paste mentality, I do not believe that the GoF book promotes that. They explain the concepts and the drivers behind each pattern using traditional OOP notation systems which, at that time, meant Booch 93 (which is outdated. The current OOP notation system is UML). There are code samples but I do not believe that the intent of the code samples is to copy and paste them into your solution. Rather, I believe that the code samples were included for illustrative purposes only. The book gives advice and examples on doing good OOP design but not cookie cutter recipes.

What do you think? Are design patterns an effective way of learning good OOP design or are they an irrelevant crutch?