Josh
No Boilerplate"A modern developer need not know the Gang of Four "Design Patterns",
but they should at least have forgotten them."
Agree? 🤔
boost appreciated, let's find out!
Yep, still relevant
No, it's not 1994
The what patterns? (see replies)
Poll ended at .
This freakin' book https://en.wikipedia.org/wiki/Design_Patterns
It's got names you'll recognise:
- Factory
- Adapter
- Proxy
- Singleton
etc
But was designed for a C++/Java/Smalltalk world.
IMO, if your language has first-class functions and closures, you don't really need them...
Apoque@noboilerplate Yeah, I agree Factory is by far the worst. It's just a `fn() -> impl T`/`Supplier<? extends T>`
That's one thing that Java 8 really rubbed in my face. There were _SO_ many single-function interfaces that I replaced/deleted with closures.
Jaycie@noboilerplate Hell yes! Hung a lampshade on this when xe were contributing to the CoffeeScript Cookbook.
Viiri@noboilerplate I would argue further that it was designed for “classic” C++. We have C++20 now and most of these are obsolete in that context. Modern C++ has design patterns all of its own.
Jacket@noboilerplate Interestingly, the method factory is pretty much what rust implemented as traits. I think at least some design patterns can be used by programing language designers as feature needs.
Marc@noboilerplate I kinda agree with the quote: the best place to be is to know they exist, but ignore them most of the time. The second best place to be is to not know they exist. The worst place to be is applying them like gospel.
Houston Bova@noboilerplate I voted yes, but that’s not to say that all of them aged well.
I use Builder and Strategy pattterns almost daily though.
It’s all about finding the right tool for the job. And learning about more of them (even if they’re less useful recently) will also be beneficial to that task.
@zethtren yeah, I'm along the same lines, but I wonder if, say Builder, would even need a name if we were all in the habit of casually returning closures from functions... 🤔
@noboilerplate Named or not it’s still a behavior I feel.
It’s nice to be able to talk about things like this quickly.
Phrases like Mutating methods, methods, associated functions, functions, monads, etc make it really easy to communicate a design. More importantly, they make it easier to reason through the initial design.
All functions returning closures would be an interesting world indeed. It might be a barrier for some to have to think abstractly before thinking at all.
Devon Morris@noboilerplate familiarity with them is important but strict adherence and implementing them in an OO fashion is outdated for sure.
Iirc in the book they present the patterns as a common language to talk about common problems in software engineering.
Furthermore in same languages some patterns are just “languages features.” E.g. Strategy pattern is just implementing an interface (perhaps not even formally for dynamic languages) and applying function composition.
Nicolai@noboilerplate I was thinking about that recently too. It feels like it heavily depends on what languages you are using. When I was learning (and even teaching!) them it never felt that relevant. Now I have a job as a Java dev and for the first time I actually need and use them. It feels like more modern languages just have better ways of dealing with those kinds of problems where you needed design patterns in the past.
ben@noboilerplate I said no, but it’s not because it’s not 1994 — it’s more that I think they’re language specific. They might be relevant if you’re writing C++, or Java; but they’re less likely to be necessary in Ruby or Go or Rust, because other language features may make them unnecessary (or at least some of them).
Conversely: go ahead and learn them but also know when they do and don’t apply to your language.
b4ux1t3 
#1️⃣@noboilerplate as with all things: it depends.
Design patterns as a concept exist as a sort of lingua franca in software development.
It doesn't matter what language you use, a repository pattern is a repository pattern; it may be implemented with a repository object in dotnet, or a repository module in rust, or a separate service fed by a message queue; the pattern is flexible enough to describe a way of solving a common problem without reference to an actual implementation. 1/2
@noboilerplate but, you hardly need to read a book on to get the benefits of abstracting away persistence to a separate, discrete place; I was using repositories long before I knew it had a name, because it's common sense once you've experienced the problems that it solves.
So, like, I don't think a developer _needs_ to familiarize themselves with the "official names" of common design patterns. But it doesn't hurt, so long as you take them as what they are: patterns, not implementations. 2/2
@noboilerplate P.S., you'll notice I didn't mention any of the big four, because I feel like those four are often overly prescriptive of implementation. They don't _have to be_, but they are. But there are lots of design patterns, and looking at the general concept of patterns is, to my mind, more useful than examining four specific ones from a book.