Here is an interesting discussion about the dangers of design patterns. Design patterns can be a great way to solve problems, but many times they become an excuse to over-architect solutions. Design patterns should reduce complexity. If they introduce more complexity, you are doing something wrong.
The myth of design patterns is that they will make it easy to solve problems that you haven’t through of yet. This sounds great in theory, but it is easy to end up “gold plating” the software by building in flexibility that will never be used.
The real power of design patterns is in solving existing problems. A lot of the times this means they will be introduced when you are re-factoring code. When the code starts becoming complex and a design pattern makes things simpler, then it might be a good time to use one.
I’ve inherited a project that makes extensive use of design patterns. In some places the patterns make the code simpler. For example the chain of command pattern is used in several places, so once you understand how the authentication piece works, you understand the principle behind several other key components.
Another pattern that shows up a lot is the factory pattern. While this is a great way to decouple code, it is only beneficial if you gain some type of benefit by having the code loosely coupled. I ran into an piece of code the other day where a factory created an object and I needed to know what it was. I had to look through 5 other java classes and two configuration files to figure it out. In this case, using a pattern made things much more complicated and there weren’t any significant benefits.
Patterns need to be used to solve real problems. If you try to use them to solve every potential future problem, they become a liability.