This book was written before Java for C++ developers (amazon shows 1994).

Edit: I agree with your opinion. Just wanted to show that this problem is much older and related to other languages too (probably with the similar OOP implementation).

The book has examples in both C++ and Smalltalk.

That's very interesting. I haven't read Design Patterns. I have read A Pattern Language, and the Timeless Way of Building, by Christopher Alexander, and Patterns of Software by Richard Gabriel. It's been my understanding that Design Patterns had only a couple of dozen patterns (which turn up again and again in Java code) and prescribed their use generally, but if they're only examples of patterns, and programmers are encouraged to invent their own (which I do anyway), it might be worth a read.

> which turn up again and again in Java code

This is true, but it's an effect, not a cause of the book. "Design Patterns" is older than Java. They wrote it based on patterns they saw mainly in Smalltalk and C++.

> prescribed their use generally

Like "A Pattern Language", "Design Patterns" reads more descriptively than prescriptively. It's, "Here's a thing we saw people do. Here's what problem they were solving with it. Here's the context of their problem. Here's the positive and negative consequences."

GoF's Design Patterns, for all its flaws, was never intended as a prescription or even as an exhaustive description of every design pattern. It was a recording of commonly used and battle-tested patterns. I think the motivation was good; the bad thing was that it became some sort of bible to be followed blindly. I don't think that was the intention of the authors, though.

I think it's not fair to the authors. As you say they are clear about the patterns being examples. However, there seems to be something about the book or maybe patterns in general that make it seemingly impossible for many developers to not look for use cases of these patterns and start using them in cases that don't quite match. I lead a book club at a post employer where we read the GoF. I constantly emphasized that these are examples of how we might reason about OOP and that they are inappropriate more often than not even though you think they are a fit. Yet, of course some people started suggesting them frequently. I think the problem might be that the first part is a support quick read and then you spend a huge amount of time reading the catalog. Once you understand them, you see how nice the patterns are on their own and you want to use them. They are pretty and you've spent time learning them. So it's only natural. It's a beautiful mental trap.

> However, there seems to be something about the book or maybe patterns in general that make it seemingly impossible for many developers to not look for use cases of these patterns and start using them in cases that don't quite match.

Perhaps. But consider the background. People write code that isn't very well designed all the time. Maybe you just see these patterns misused so often because you can identify and name them. This is entirely the point behind the book – so we can identify these common patterns and talk about them at a higher level.

You've probably seen bad code where you can't describe what's wrong with it succinctly a lot too. But you don't have the option there of saying "oh, they've used a factory there when they shouldn't have" because the bad code doesn't follow a pattern that you know / have named. So all of those cases just get filed away in the fuzzy "bad code" category instead of being an example of a pattern being misapplied.

By definition, almost, something being a pattern is going to be something you see misapplied simply because that's part of the purpose of design patterns – so you can comprehend these problems better.

There already is a vocabulary for programming design patterns (monads et al) but people seem to hate/fear them for some reason.