Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

A critical examination of design patterns in software development, arguing that many patterns are overcomplicated names for simple programming concepts. The author contends that patterns like Command (which is just a function) and Strategy (which is just an interface) create unnecessary cognitive overhead and that developers naturally arrive at these solutions through iterative design without needing formal pattern terminology. The piece advocates for focusing on underlying principles rather than memorizing pattern names, suggesting that good architecture emerges from composing language features to solve problems rather than following prescribed patterns.

If I hear "design pattern" one more time, I'll go mad

If it’s only you doing it’s a workaround. If everyone is doing it’s a design pattern.

Hi Alisa (her name is in the about page)
I hear where you are coming from. There is a lot to learn in our field and to learn these additional terms may seem so redundant when a lot of the patterns are baked into programming languages these days.
But to address the core of your argument, I would like to present you with a challenge. What’s the difference between a proxy, decorator, adapter and facade?
They all use interfaces, classes and composition. At a glance they look very alike. Their intention is very different though.
You mentioned “you say command, I say function delegate”. Ok but I can use a function delegate as an abstract factory too. Do you see the problem?
We have these terms because that’s how things evolved over time and got standardized. If I say to my colleague “go and setup an adaptor for that API” he knows that he’s going to build a class that will translate data from one domain to another.
You might say “no I am just decoupling myself from an external vendor”, that’s not the same thing. You can be tightly coupled and still use the adaptor. Decoupling is a very loaded term. You could mistake it to mean “oh I need to build a layer of abstraction so that I can switch to another vendor if I needed to”. If that was your intention, fine but it’s not the same as an adaptation.
PS: looking at Wikipedia for definitions is very academic. The other commenters have good resources that explain those concepts in much better terms.

Design patterns exist only to be violated.

I’m a simple person, if I write code and it looks bad I’ll try my best to clean it, read about it, see some terms given for nice blocks of code, immediately forget them, but not the actual way of doing things, rinse and repeat.
Then fail the interview cause I don’t know what a closure is despite using it automatically like a muscle memory.