Thank you for writing this. When I first read the GoF Design Pattern Book I thought "this is the reason, why the code in my project is bloated, unmaintainable and shitty".
Thank you for writing this. When I first read the GoF Design Pattern Book I thought "this is the reason, why the code in my project is bloated, unmaintainable and shitty".
Not sure if you know the history, but the authors of the book really only collected the patterns that they had seen around them in Smalltalk and C++ code. They wrote a catalog so we could all refer to the same name instead of using different names for the same concept. They identified the common problems that these patterns tried to solve and they also identified the trade-offs. Oh yes, they identified trade-offs!
Unfortunately, many developers thought that they had to put as many patterns as possible in their code, which was not the intent of the GoF. Ralph Johnson said that they received emails like "I have now used 15 patterns in my project, do you think we should use more?"
Andrzej mentions in his blog post that Java (and C++) lacks dynamic capabilities so this is why sometimes, you need these design patterns to make your code more easily extendable. Other patterns are good even with dynamic languages (observers...).
They're not 'Do this, and you'll have good code', they're just an observation that good code may often use many of these patterns - not because they're forced in there, but because the solution simply maps well to that kind of model.
It's been a while since I read it, but I remember using the book itself as ammo for arguing when not to use particular patterns. They cover trade-offs, and the situations when the pattern may be appropriate or not.
It depends on the programming language one uses, really. You won't find many references to these patterns on Python's mailing list (or at least I didn't when I was new to the language and used to spend a lot of time there, ~6-7 years ago). Also, when I've tried to learn Lisp or Erlang I didn't find any mentions to such particular patterns (or maybe only in passing), the focus was on something else. And I'm sure there are a lot of other languages outhere who don't bother with patterns.
Adapter is a generic name. Compatibility modules that enable python code to run with python 2 and python 3 are adapters. For example: https://github.com/bartdag/py4j/blob/master/py4j-python/src/...
As for the visitor pattern: http://docs.python.org/library/compiler.html#module-compiler...
They're just not called design patterns. But note that the things in GOF weren't called design patterns in C++ until 1995 either (the GOF book largely predates real use of Java). They were called techniques, or just things you might see in multiple projects.
I am pretty convinced that GoF did not expect how popular their book may become. Looking back, it is always easier to judge.
Looking back, with no offense to GoF, what happened can be understood. GoF did a great work for all these "I badly need to sell something new and hot to all these saturated development shops" guys. Read the pattern book once, teach it a hundred times for 2000$ a person. Great stuff.
Now, of course it is due to the single developer to use patterns or not. But the average developer is - well average. Using a pattern is much easier than to understand, when to use and when not to use.
I indeed should have been more precise in my statement: our code got bloated and unmaintainable because there are pattern all over. This is not GoFs fault, it is the fault of all the developers who just read the book and want to apply everything instantly, everywhere. It is also the fault of the community, who did not recognize at once, that pattern should be used only, if they solve a problem that is hard to solve without patterns.
"You've got a singleton class with a single method and no members . . . why don't you make this thing a function?"
"Uh, it wouldn't be a pattern then, would it. Um, would it?"
And the XML. Oh, dear Lord. I have a doctor's slip now stating that I am allergic to XML and that's the reason I'm breaking out in hives, whooping for air and leaving the room.
I sometimes wonder what would have happened to the software industry if the entries in GoF had been written in a different order. Would we see a plague of Visitors and Observers?
[edit] I didn't mean to sound so negative about GoF. Know the patterns so you know when to use them, and when to avoid them. You can't debate these decisions when you're ignorant of design principals and history.