Even before I ever read GoF, I found myself using their design patterns in my object-oriented code (i.e. "reinventing" what already existed). At the time I didn't think it was any magic feat, it's just the way I organized the code. It's nothing surprising, all OOP developers end up doing this -- the abstractions provided by an object-oriented language naturally lead to the design patterns we see in the GoF book. In fac,t in the introduction of the book, the authors describe how the patterns came from existing, real-life software which they found worked well in practice. Reading GoF is useful to an OO programmer because whenever they encounter a difficult problem, there's usually a "pattern for that". Oh I need to manage complex states and state transitions - use a "state pattern". I need to route messages to any object that desires the message feed - use an "observer pattern".

As the article states, GoF patterns are a tool and shouldn't be treated anything more or less than that. I've worked with developers who treat design patterns with religious sanctity and their designs are convoluted with forced GoF patterns. The result is bloated code that is difficult to follow. Likewise I've worked with developers who think they're a scam and prefer to "cowboy" their own solution which either ends up reinventing a design pattern or just being plain ugly.

I saw some comments in this thread implying how language paradigms other than OOP (primarily functional) eliminate the need for many of the GoF design patterns. This is true, but it doesn't mean that functional (or whatever paradigm) languages do not have design patterns -- they have their own design patterns as well. For example, the concept of a "monad" can be considered a design pattern to implement side-effects in pure functional languages which lack that feature. Some design patterns transcend language paradigm, for example, Model-View-Control (MVC) is universal to procedural/imperative, functional, and object-oriented code. Design patterns also exist for concurrent computation -- a great example is "The Little Book of Semaphores" (http://www.greenteapress.com/semaphores/). The book details multiple "design patterns" for solving common problems with concurrent computation in languages that provide semaphores and threads as the primitive concurrent computing abstractions. However, to help make the point of the other commenters -- using a language designed for concurrency (e.g. Erlang) eliminates the need for a lot of these design patterns. On the flip side, using something like Erlang introduces a whole new set of problems meaning you need a whole new set of design patterns!

What I think was revolutionary about GoF was the coining of the term "design pattern". It's analagous to the concept of "algorithm" but not quite...it's more general than that. What's beautiful about the term is that it's applicable to more than just programming, but rather any sort of engineering, design, or problem solving. As the author of the article demonstrated, there are even architectural "design patterns". In any field, you'll have design patterns (they may not call them that) and books on them that predate GoF. However, the way GoF documented them as wonderfully and clearly as they did in their book...it's just beautiful.