> I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation.
I don't agree at all. I feel that those who criticise design patterns as solution to practical problems are completely missing the point of design patterns, and the whole reason they have the name the have: design patterns. I'll explain.
Design patterns are solutions to common design problems, but "problems" isn't the kind of problems you think it is. It's "problems" in the sense that there are requirements to be met. A state pattern is a way to implement a state machine, but you still have a state machine and a state pattern if your state classes don't handle state transitions.
More to the point, look at singletons. It's irrelevant if they are implemented with a class or a closure or a module. What makes a singleton a singleton is the fact that there is an assurance that there will be a single instance of an object. Does an implementation that allow multiple instances or doesn't return the same instance qualifies as a singleton? Obviously not.
Design patterns are recurring solutions to recurring problems. They are so recurring that they get their name and represent a high level concept. A message queue is a design pattern. An exception is a design pattern. Lazy loading is a design pattern. Retries and exponential backoffs are design patterns. Etc. Is anyone arguing that Python has none of it?
So many people trying to criticise the GoF but they don't even bother to be informed or form an educated opinion.
I see you’ve been downvoted.
Design patterns aren’t solutions to common design problems. They’re after the fact descriptions of solutions for design problems. That’s the issue. That’s the beef. Everyone thought of that book as a cook book instead of a naturalists’ musings on an ecosystem, which is what they are.
Those of us who designed before people discovered that stupid book were constantly asked what the differences were between this pattern and that. And the book just isn’t thick enough and Eric Gamma was just trying to complete a thesis not write a book, so despite having at least 8 years in industry before completing his masters he cocked it up. And ruined Java in the process.
We had a contemporary of Vlissades teach a class at my last company and he crystallized all of my suspicions about the GoF book and added a whole lot more.
My advice for at least fifteen years is, if you think you want to read GoF, read Refactoring instead. If you’ve read Refactoring and still want to read GoF, read Refactoring a second time because it didn’t all sink in.
Refactoring is ten times the value of GoF for teaching you how to do this trade and how to break up architectural brambles.
> Design patterns aren’t solutions to common design problems. They’re after the fact descriptions of solutions for design problems. That’s the issue.
No, they are not. They describe a way to design something. They are called design patterns. It is in the name, already. Consider instantiating an object. You can have a factory, or you can pass a parameter object, you can implement a builder. Perhaps you can use a flywheel? In testing there is also object mothers.
Did you noticed that each term describes a very specific and concrete approach to tackle a single use case? There is no "after the fact" anything. Claiming design patterns is something you do "after the fact" reflects a complete failure of understanding what design patterns are and how they are used.
No wonder people complain about design patterns. They are complaining about their own failure to understand what they are and how they are used. Of course people complain about things they don't understand.
> Those of us who designed before people discovered that stupid book were constantly asked what the differences were between this pattern and that.
The book didn't discovered anything. At best it contributed to standardize names used for popular design patterns.
Also, the telltale sign that people are shit talking design patterns out of sheer ignorance,and willful ignorance, is the fact that there are over a dozen reference books on design patterns. Reference authors such as Martin Fowler even wrote themselves two or three books worth of patterns. But GoF is the only one being attacked all the time? Why? Because of ignorance.
I also completely disagree with the builder description.
It sounds like they've not had to use it for any meaningful work, and basically described a constructor. Yeah, named parameters are great, and I miss them when I don't have them, but if you think a builder only works like this
Object.setX().setY().build()
Then it tells me that you haven't built anything meaningful. It's a way of building a state and running an operation at the end in a contained manner. If your build method doesn't run some sort of validation then it's probably a waste of time, might as well just call setters, return this and call it a day if you want to be verbose and chain commands.
I mean, people usually call those 'feature' when they're built-in. I would never call 'lazy evaluation' in Haskell a design pattern, because it's part of the language.
If I have to implement something similar myself in C++ however, I'll use a niche design pattern.
> I mean, people usually call those 'feature' when they're built-in.
No, that's specious reasoning. A message queue is still a message queue if you use one provided by the OS. An exception is still an exception even if it's provided as a standard component. A state machine is still a state machine regardless of how you choose to implement your concrete implementation.
Design patterns are all about the patterns followed when designing something. That's it.