Ask HN: Are design patterns still a thing?
When I learned C++ 10 years ago, we had a textbook basically teaching C++ through design patterns. I remember them to be mentioned quite regularly, including in job offers. Nowadays, they don't seem as big as they used to be, and I did not hear about them for a while.
What is your recent experience with them? Are they still a thing?
9 comments
Everyone was still off inventing their own wheel 10-15 years ago. Today, most languages provide libraries that cover the majority of the use cases for which you would have written your own implementation of a design pattern. To add to this, languages have shifted towards providing functional programming extensions that move away from the OOP perspective on design patterns to a functional one.
In a sense, design patterns are everywhere. Some easy examples: each time you use a foreach, you are using the iterator pattern. If you use filter or Where on a collection, you are using a visitor pattern implementation.
I would add that people are coming to realize that SOLID principles lead to code that is easier to write, reason about, and maintain. Whereas the GoF patterns were the right knowledge 10 years ago, SOLID principles are the right knowledge for today.
In a sense, design patterns are everywhere. Some easy examples: each time you use a foreach, you are using the iterator pattern. If you use filter or Where on a collection, you are using a visitor pattern implementation.
I would add that people are coming to realize that SOLID principles lead to code that is easier to write, reason about, and maintain. Whereas the GoF patterns were the right knowledge 10 years ago, SOLID principles are the right knowledge for today.
Basically this. I do see the facade pattern used a lot in projects still however.
Well, kind of. I need to cure singletonitis from time to time. Apart from that, not where I am working. However, the dominant cause would be that they are not that useful for embedded/safety systems though.
They're certainly less fashionable than they were 20 years ago, and I'd not expect to see them talked about so much in job ads.
It's a bit odd, to teach a language through design patterns: design patterns are really best-practice workarounds beyond the language where the standard language toolkit doesn't provide an obviously best way of solving a problem. It's a run-before-walk approach.
You might be interested in this story, Design Patterns 15 Years On - http://lambda-the-ultimate.org/node/3655 (link to LtU discussion, which has some other resources).
It's a bit odd, to teach a language through design patterns: design patterns are really best-practice workarounds beyond the language where the standard language toolkit doesn't provide an obviously best way of solving a problem. It's a run-before-walk approach.
You might be interested in this story, Design Patterns 15 Years On - http://lambda-the-ultimate.org/node/3655 (link to LtU discussion, which has some other resources).
It was not the best class ever, for sure!
That's an interesting link, I never saw that way. Probably because how I learn them too, i.e. a mandatory thing to know.
Now I mostly wonder why/how did they get so big.
Now I mostly wonder why/how did they get so big.
It depends. Have you looked into Haskell land lately? It's the 90s again there.
I did a bit of haskell, but not that much.
From what I could see, it was more about stack of monads and compositions...
Can you elaborate a bit?
I guess that the point was, Haskell is still developing patterns for solving common problems. Many of the uses of monads could be considered design patterns.