Software Design Patterns - Overview and Rant

General reusable solutions to commonly occurring problems in software design, made popular by the 1994 book by the "Gang of four". Lately I am leaning towards dismissing them as buzz-words that wanna-be l33t hax0rs use to impress/confuse and a favourite question of interviewers. More and more patterns that I come across in reading seem to be post-hoc descriptions of designs that I or other developers have used frequently without attributing a spiffy name to. For example, the Strategy pattern - a design pattern whereby algorithms can be selected at runtime, implemented using concrete strategy classes implementing a strategy interface. How is that different from polymorphism? If anything it is a subset of polymorphism and adds nothing new. And the Iterator pattern??

I admit I do find some pattern identification useful. For example, the Facade - exactly what it sounds like, defines a higher-level interface that makes a subsystem easier to use.

Although the Singleton is still often identified as a pattern, there is growing belief that it should really be classed as an anti-pattern. Some of the drawbacks identified include the following:

• The limitations it introduces may be unnecessary, ie: a sole instance may not actually be required in a given situation. Additionally these limitations may cause threading issues.
• Singletons introduce global state into applications resulting in dependencies in the design being hidden inside the code, rather than obvious dependencies highlighted by method parameters for example.
• For purists, Singletons mix two different responsibilities in the same class, one of them being the control over the number of instances of itself. This may be better handled using a Factory to encapsulate creation and limit instances.

In short, although I think the study of design patterns (and anti-patterns) is great for building up a budding developer's abilities, I am somewhat sceptical about 1) the introduction of new terminology to describe existing simple solutions to a problem, that really don't require another name, and 2) the proliferation of patterns in areas where something simpler and more customised would be a lot easier to understand and maintain.