[St-Clock]

You are right. The GoF only promoted bloated code. Who in their right mind would use patterns like the Observer, the Adapter, or the Visitor?</sarcasm>

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...).

[paganel]

> Observer, the Adapter, or the Visitor

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.

[St-Clock]

You did not hear about observer, but you probably heard about publisher/subscriber (most gui frameworks use this, even wxPython with pubsub).

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...

[kenjackson]

All languages have patterns. Case analysis is a common pattern in Lisp code I've seen. Another one is map-reduce. Tags are another one.

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.

[dpark]

Every language has design patterns. The patterns are different depending on the language, though. You don't use the observer pattern much when you've got proper delegates (or closures), for example. Design patterns are just the things you end up doing over and over in a language. MVC is a design pattern. Even something like Rails itself could be said to be a codifying and standardization of a set of design patterns.

[eropple]

Exactly. What many GoF critics seem not to understand is that Design Patterns is descriptive, not prescriptive. It's "what we've seen," not "what you should use."

[msluyter]

I've heard people say that, but if that's true, why didn't they include many of the (much more commonly used, IME) patterns like Big Ball of Mud, Stovepipe System, Spaghetti Code, etc...? There's lots of nightmarish patterns/techniques that were omitted. I find no plausible way to account for that other than that the patterns are (perhaps implicitly) prescriptive.

[bmm6o]

Those are covered in the anti-pattern book.

[msluyter]

Reinforcing my point. If those are "anti" patterns, they must be bad, right? Hence, patterns as described in GoF are good.

[bethling]

I think there's a line between "These are patterns that we have seen work" and "These are good patterns so use them". Back when I first read the book, I was pretty junior and I remember thinking "oh! I can use this...and this!". And built "wonderfully" over-architected code. Now I'll run into situations where after I starting working on some the solution I have resembles a pattern - and it's nice to be able to use common terms that the other developers will understand when you discuss it.

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.

[jtheory]

The GoF book itself doesn't describe them as good, unequivocally.

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.

[mironathetin]

No sarcasm necessary.

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.