Unpopular opinion, but I think the Design Pattern book created more problems than it solved. It encouraged people to come up with clever designs for object-oriented systems. Object-oriented systems themselves tend to get too complicated. And then making people think they have to use some kind of smart design encourages an addition of complexity.

The first rule of design should be make it as simple as possible. And this book, I think, does the opposite for many people.

I think design patterns should be more descriptive, but people try to use them prescriptively.

Being able to say "circuit breaker" pattern or "visitor" is a time efficient way to communicate complicated ideas. Its value is being able to conserve the limited bandwidth speaking has.

Bad coders will always find something or another to justify their work with and it just so happens the most popular book is often referenced, for good and bad.

I don't think that is an unpopular opinion at all, and I like OO programming just fine. People latched onto Design Patterns like that were tablets from God whereas the book was better thought of as giving a taxonomy to existing practices (and not even best practices.) Different subsets of their patterns work better in different languages, and it is pointless to force a specific pattern into a design where it doesn't fit naturally.

I think it is useful to say "This design could be thought of as a delegate" when explaining your code, but saying "We need a delegate design pattern here" is needlessly prescriptive.

100% agree. The worst offenders imho are DRY and inheritance. In most cases it causes garbage code that adheres to some lofty goals but sucks to be maintained. We actually do the opposite of DRY: isolate behaviour, even when shared. If complex enough and shared: build a lib. But one use case = one app functionality. We are so happy and productive with that. Throw in ports + adapters and use cases (= one feature) and you're set.

But GoG saids to use composition over inheritance

I tend to agree. The OOP-all-the-things mantra created many problems; lots of books were printed (more than necessary), and lots of evangelists made their name on unnecessary abstractions over abstractions. One might blame Java for that, but it's a chicken-and-egg problem.

AFAICT, I think your opinion is fairly widely shared.

Yes. It's become a popular opinion over time. People lauding GoF today should be viewed with skepticism.

Unrelated to the topic, but I worked with Jim (blog author) over a decade ago and he was an awesome guy to work with. Real standup human being altogether, in addition to writing good ruby.

Jim, if you're lurking around, hi, hope all is well!

I'm no great fan of GoF, it leads off saying to use composition, then most of the patterns just go hog-wild with inheritance anyway. But I don't think anyone has a lock on the term "delegation". It means "pass off responsibility to something else", and it doesn't need to depend on any single mechanism hardwired into the language. Whether `self` stays intact across dispatches or you need to pass `this` explicitly to your delegated handler isn't the central point.

They're both likely a reference to the infamous political faction in China in the 60's.

https://en.wikipedia.org/wiki/Gang_of_Four