I always saw "design patterns" as a symptom of the OOP culture. The mid 2000s was the worst era for this. Everything had to be packaged as nouns and programmers saw their "profession" as being about defining taxonomies of design patterns and ideally encoding them in abstract classes.

This is what leads to almost satirical situations where a "command evaluator abstract class" is a way to express "a function"

Parodied in dating design patterns back then…

I think these are chiefly about working around limitations of 2000s Java, which was (no idea about newer releases) a very verbose and inexpressive language.

we need to change stuff up every once in a while to get people to buy the new books and license the new boilerplate. If things kept working the way they always have, people could just buy the old books and use the old software, because it works fine, so we need to change our culture to ensure it becomes obsolete.

I got my copy of the GoF from Thriftbooks for something like $3.

Chapter 1 (introduction) and Chapter 6 (conclusion) are the only two chapters I found useful in my job. And I feel like I got my moneys worth.

Essentially every complaint I’ve even seen about design patterns is addressed in those two chapters. It’s clear that nobody ever reads those parts. Oh well. Continue on complaining about things that were addressed in the 1990s.