Design patterns are just tools
timbenke.de
timbenke.de
Design patterns are solutions to recurring problems, but it's important to note that they are not the only solutions, and also that the "commonly recurring problems" are highly context dependent.
Most of the OOP problems go away if you use more flexible programming languages or paradigms. New meta-patterns like DCI also invalidate the "recurring problems."
Thus, the critical thing to recognize is that the expression "commonly recurring problems" is a trap, in that it is easy to assume that it is normal or expected for those problems to occur, when in actuality they occur as a consequence of large architecture decisions that can and perhaps should be made in such a way as to eliminate those problems outright rather than solve them.
None of the aforementioned invalidates the concept of design patterns, however I feel it is difficult to say they are "just tools" as if it's perfectly reasonable to expect to have to use them on a regular basis as if programmers have no say in the matter of whether the need for those tools will or won't apply.
Spare us the myth. This isn't reddit.
Perhaps you have something specific to share about why that or any other point is wrong? Perhaps an interesting viewpoint on myths and how they take hold?
This is primarily because of the languages books like Gang of Four use to illustrate design patterns.
In reality however, most design patterns date back to Smalltalk which (ignoring multiple-inheritance for the moment), provides the most flexible and dynamic representation of objects that I've seen to date.
----
Another myth is that design patterns were invented.
The the Gang of Four can be quoted as saying they merely are documenting patterns that will naturally occur in the course of writing code. If you use run-time-binding to determine an objects inteplementation, then congratulations you have Inversion of Control whether you want to call it that or not.
The whole purpose of design patterns is to give us a common language so we don't have to describe our code, but can simply call it by name.
It is not necessary in ST, because ST's syntax includes the semicolon operator for cascading messages to a single receiver. In effect, the pattern is "baked into the language."
Patterns are detected - abstracted from what experienced people usually do in certain circumstances.
But you could come up with that for yourself by comparing the need for a visitor pattern in, say, Java and Python respectively its implementation in both.
[EDIT] Of course other programming paradigms can develop other patterns, if they are confronted with problems they cannot solve from the outset. That was more raganwald's point.
Of course, that's the point of patterns.
This is exactly right. Even basic support for first-class functions makes a huge difference. There have been occasional posts around about classic design patterns in JavaScript, and the overwhelming feeling you get when you see most of the implementations is "Yes, but... why?"
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.
Even? Alexander invented them. He also disowned their use in software - something you'd think software pattern advocates would pause to consider, but never do.
They are tools used by software engineers to solve problems.
The unfortunate thing is that many software engineers fail to realize these are just tools and confuse them as being the ends as opposed to being the means.