The GoF design patterns book has two core, very closely related, problems.
The first is that it doesn't make enough of an effort to present "design patterns" as a conceptual framework. Can you program without using design patterns? No, you cannot. You are always using design patterns whether you know it or not, you're just using ad hoc design patterns without realizing it when you don't think you're using patterns. The book's failure to elucidate commonly used ad hoc patterns as well as common anti-patterns is one of its principle shortcomings. This is something that the refactoring book did much better, by providing examples of how things can be engineered in different ways and why one way might be desirable over another (and how to transition between them). Instead the GoF book largely presents a canonical list of some design patterns, giving people the false impression that these are special and unique versus merely a sampling of ways one might do things.
Additionally, the GoF book doesn't make it clear that each design pattern exists to work around specific constraints, and thus doesn't educate the reader when and why the design pattern should be used, and when not. The GoF list of design patterns is very much tightly coupled to the peculiarities of Java at the time the book was written. Many of the design patterns aren't necessary outside of that environment. For that reason, a lot of the design patterns in the book are either obsolete or so seamlessly built in to popular languages that it's not necessary to implement them as described in the book. Many of the more advanced "behavioral" patterns from the book are essentially ways to work around the fact that Java didn't have first class function, when that changes the design patterns that you end up with become very different.
A lot of the GoF's list of design patterns just aren't that useful anymore in modern languages, even though many of them are as applicable as ever (modern languages bake iterator support into the language, for example).
Additionally, the GoF design patterns break down into two categories: everyday patterns (like iterator, factory, proxy, or adapter) and sometimes patterns (like flyweight). This means that most of the patterns shouldn't be used in every project. Because the design patterns in the original book are somewhat out of date and because there's been so much cargo culting around the GoF patterns there's grown a substantial backlash against patterns. So people tend not to describe new patterns in such a way, even though they should. The concept itself is quite sound, but it requires diligent effort to ensure you're applying it well.
> Additionally, the GoF book doesn't make it clear that each design pattern exists to work around specific constraints, and thus doesn't educate the reader when and why the design pattern should be used, and when not.
Quite to the contrary. I don't have my copy handy and haven't cracked it open in years, but I recall clearly that they presented design patterns as reusable solutions to commonly occurring problems. And for each pattern they outlined, they explained what the problem was that it was intended to solve.
Alas, the part about patterns being solutions to specific problems was lost on many developers, who shoveled in applications of patterns where their corresponding problem didn't exist. And rather than a more modular, understandable, maintainable codebase, an inscrutable mess was often the result.
I do have my copy at hand. While they do try to get across the concept that not all patterns are suitable for all cases they do a remarkably poor job of it. The "applicability" section of most described patterns is a simple bullet list of 3 or 4 very vaguely worded sentences. This is, as evidence has proven, wholly insufficient. There should have been much more effort into trying to educate readers on the applicability, and non-applicability!, of each pattern, explaining the constraints that made the pattern necessary or desirable, laying out examples of other ways to achieve the same functionality, and also explaining the costs and extra complexity of relying on a specific pattern.
The patterns are essentially Smalltalk-based, though the authors had been implementing the same ideas in C++ - Gamma in ET++ and Vlissides in InterViews.
I agree with your second paragraph, but I also think that as with every book, you have to understand the context it has been written and it is always good to have a wider picture and know how something can implemented using a different paradigm and how things relate to each other.
I am not sure I can agree with the claim that everything written is following some design pattern. Perhaps it is an known anti-pattern instead or completely ad-hoc solution that is neither but is nonetheless a good design.
Design patterns are architectures that have been distilled from the field experience to be useful to solve certain problems resulting in a good design. Therefore it is also quite natural that they get integrated into language designs over the time.
Have you read Design Patterns? The viewpoint you have here is typical of people who have absorbed it osmotically from software culture, but haven't read the work itself. You say:
> Instead the GoF book largely presents a canonical list
> of some design patterns, giving people the false
> impression that these are special and unique versus
> merely a sampling of ways one might do things.
From the Introduction:
"Despite the book's size, the design patterns in it capture only a fraction of what an expert might know. It doesn't have any patterns dealing with concurrency or distributed programming or real-time programming. It doesn't have any application domain-specific patterns. It doesn't tell you how to build user interfaces, how to write device drivers, or how to use an object-oriented database. Each of these areas has its own patterns, and it would be worthwhile for someone to catalog those too."
> Additionally, the GoF book doesn't make it clear that
> each design pattern exists to work around specific
> constraints, and thus doesn't educate the reader when
> and why the design pattern should be used, and when not.
"No discussion of how to use design patterns would be complete without a few words on how not to use them. Design patterns should not be applied indiscriminately. Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and/or cost you some performance. A design pattern should only be applied when the flexibility it affords is actually needed. The Consequences sections are most helpful when evaluating a pattern's benefits and liabilities."
Literally every single pattern chapter in the book comes with an explicit section describing when you should and should not use it.
> The GoF list of design patterns is very much tightly
> coupled to the peculiarities of Java at the time the
> book was written. Many of the design patterns aren't
> necessary outside of that environment.
As another commenter noted, Design Patterns is older than Java and makes no mention of it. The patterns are often particular to object-oriented languages, but I don't know what else you would expect from a book titled "Design Patterns: Elements of Reusable Object-Oriented Software".
> Many of the more advanced "behavioral" patterns from
> the book are essentially ways to work around the fact
> that Java didn't have first class function, when that
> changes the design patterns that you end up with become
> very different.
The book uses Smalltalk as one of two example languages. Smalltalk not only has first-class functions, but all blocks used for control flow in Smalltalk are essentially closures.
The Command pattern isn't just "how to take first-class functions in a language that doesn't have them". It also talks about commands that are undoable, or that can be logged, or serialized and deserialized. It's as much about the objects that create the command, receive the command, and have the command invoked upon them as it is the command itself.
I do wish it talked more about the relationship between commands and first-class functions (which I do here[1]), but it's not as bad as you make it out to be.
The first is that it doesn't make enough of an effort to present "design patterns" as a conceptual framework. Can you program without using design patterns? No, you cannot. You are always using design patterns whether you know it or not, you're just using ad hoc design patterns without realizing it when you don't think you're using patterns. The book's failure to elucidate commonly used ad hoc patterns as well as common anti-patterns is one of its principle shortcomings. This is something that the refactoring book did much better, by providing examples of how things can be engineered in different ways and why one way might be desirable over another (and how to transition between them). Instead the GoF book largely presents a canonical list of some design patterns, giving people the false impression that these are special and unique versus merely a sampling of ways one might do things.
Additionally, the GoF book doesn't make it clear that each design pattern exists to work around specific constraints, and thus doesn't educate the reader when and why the design pattern should be used, and when not. The GoF list of design patterns is very much tightly coupled to the peculiarities of Java at the time the book was written. Many of the design patterns aren't necessary outside of that environment. For that reason, a lot of the design patterns in the book are either obsolete or so seamlessly built in to popular languages that it's not necessary to implement them as described in the book. Many of the more advanced "behavioral" patterns from the book are essentially ways to work around the fact that Java didn't have first class function, when that changes the design patterns that you end up with become very different.
A lot of the GoF's list of design patterns just aren't that useful anymore in modern languages, even though many of them are as applicable as ever (modern languages bake iterator support into the language, for example).
Additionally, the GoF design patterns break down into two categories: everyday patterns (like iterator, factory, proxy, or adapter) and sometimes patterns (like flyweight). This means that most of the patterns shouldn't be used in every project. Because the design patterns in the original book are somewhat out of date and because there's been so much cargo culting around the GoF patterns there's grown a substantial backlash against patterns. So people tend not to describe new patterns in such a way, even though they should. The concept itself is quite sound, but it requires diligent effort to ensure you're applying it well.