Design Patterns have grown to become a standard in the field of Software Development ever since the Gang of Four published their book, Design Patterns: Elements of Reusable Object-Oriented Software in 1994. However, some people in the field of Computer Science have leveled criticisms towards Design Patterns for a few reasons, even if it is widely accepted that they are tools in the belts of developers at this point.
A legitimate criticism of them seems to be that many of the patterns are heavily language dependent, as some languages have easier work arounds for problems that present themselves in others. Peter Norvig, a director of research at Google, showed that 16 of 23 patterns from the Design Patterns book can be replaced solely by implementing them in Lisp or Dylan rather than C++ (page 9 of this PDF). Part of the argument here is that if languages don’t have the same design patterns, then those languages that do have more design patterns are requiring that developers find work arounds for their missing features.
Another issue that many seem bring up is that the emphasis on using design patterns results in developers relying on them too heavily. Similar to the Golden Hammer AntiPattern, once a developer (or team of developers) becomes comfortable with a tool or concept they end up attempting to cram the problems they’re given into some implementation that would allow them to use the solution they’re comfortable with. In this way, even if Design Patterns are intended with the intention of writing code in good practice, if they’re implemented when it isn’t necessary it can quickly turn sour.
The idea behind Design Patterns is that, if they are used correctly alongside correct Object Oriented Design principles, the patterns should emerge naturally. If you ever find yourself asking, “How can I use the Singleton Pattern here?”, then you’re misusing the tool in your tool belt. They are better viewed as teaching methods for successfully upholding good design in complex situations, in a way. If you’re writing code and it dawns on you that what you’re attempting to write is similar to a pre-existing design pattern, then you have a direction to follow. This article in particular gives a great example of an application of the template pattern, and shows how you’d get there in a natural way as opposed to forcing a pattern on a piece of code.