image created by Margaux Peltat for the Chilled Cow YouTube channel
Time for #DEVDiscuss — right here on DEV 😎
Inspired by @earthcomfy's Top 7 post, tonight’s topic is...design patterns!
Questions:
I disagree that this is a problem. As long as you recognize a pattern in code, or decide to use one, its name doesn't really matter.
When you talk about code it's useful, but not when you read (including review) or write code.
But sure it'd be better if I could remember all the patterns and their name 🤣 (particularly as they aren't many, much fewer than cognitive biases!)
its name doesn't really matter.
That means that design patterns are reduced to recipes.
But they establish a naming system, nomenclature that is supposed to make communication between software professionals more effective. That's a powerful benefit to give up when you can't put a name to it.
Indeed, that's why I also said
When you talk about code it's useful, but not when you read (including review) or write code.
😉
That's still an implementation centric mindset.
In terms of the outcome it's also important to know when a pattern is appropriate and when it becomes anti-pattern.
That's why the original 1994 GoF Pattern template had 13 separate sections only some of which are:
And yet I still think it's fine if you don't remember the names of the patterns.
Well during Job Interviews it's quite common to be asked "Give me some design pattern names and how they work"
My ah ah moments were when I realize I don't need a design pattern anymore because there is now a better solution.
General example: Strategy design pattern was useful for the GoF C++ developers, but if your programming language supports some kind of functional programming, you can safely use lambdas instead.
Java example: the Builder pattern is the best way to create objects in Java, but Kotlin has a built-in better solution in the language itself: named and optional parameters.
I then realized it's better to fall in love, not with a particular solution, but with a problem.
There's also an SO question, which discusses this in more detail. Now I'm very much interested in a more comprehensive list of language features that replace design patterns or make them obsolete.
But they are still patterns, just implemented with different methods. Strategy can be implemented with lambda.
GoF provides a concept to solve this or other problem and you decide how to implement it in your language
The need for patterns arises when people choose a programming language or a technology that lacks the necessary level of abstraction. In this case, patterns become a kludge that gives the language much-needed super-abilities.
As you said, the Strategy pattern can be implemented with a simple anonymous (lambda) function in most modern programming languages.
So instead of applying the pattern:
You just use a lambda, which is not the "strategy design pattern", in fact, renders it obsolete (unless your tech stack lacks the ability to use lambdas).
I agree, but my point is that we don't need to consider patterns as something concrete, it's just an idea/advise to solve a problem.
But I agree with your point that for majority of languages there is no need in creating a lot of abstractions to implement this or another pattern
Sure! but logically you can avoid the second bullet point because it doesn't add any valuable information:
In this case the lambda expression becomes a blueprint for many problems, and design patters are just blueprints as well.
I won't bother learning the names of all design patterns nowadays, even less to memoize all of them like it was a religion.
Still I find useful -and will suggest- to anyone learning CS to try and understand why design patterns became a thing and what's the logic they use to solve common problems, because one may extrapolate this logic even working with lambdas (e.g. "modern" Java) or Functional Programming, as it's being the norm in tones of implementations nowadays, specially in JS and for good) 😃
Answers for some of the questions:
I used to use design patterns in PHP all the time, but with JavaScript I never know what design patterns I'm using... Except composition, that's the only one I'm aware of... I've looked at patterns for functional programming, but i haven't found anything thats similar to the OOP design patterns we would use in PHP. Oh actually I just remembered factory method, I use that one too! 😁
Separation of concern between data and implementation/behavior is the only design patterns that I still adhere. It has quite an impact in performance when you can transform that data/struct into multi array and do array programming.
Recently I find ORM became appealing again. I also questioning that Component model (in modern webdev) is not the right approach for mainstream website. After experimenting with Godot in the past where you can attach any language into single scene, seems there's an evolved version of clean architecture waiting to be discovered.
I learned a lot about design patterns lastly and just i can say is so useful for projects, the MVC pattern was the first i used to develop my android app.
And now, i´m getting older refactoring and improving the code of my app lol
Honestly, I came to the conclusion that if a language or paradigm needs a huge catalog of design patterns to be useful then there is probably something wrong with the language or the paradigm. Of course there are always some 'patterns' we use. Be it monads, closures, factories or whatever, but I feel like we should use them because it makes sense and not because they exist. There were many projects I was involved in where I had the feeling the patterns were used extensively because they exist... and the level of the resulting abstraction was just ridiculous. How many times I heard the argument for a complex pattern: "it makes it easier when we have to switch x or y"... the answer to "how many times did it happen?" has always been a very low number (usually 0).
Design patterns are like cheat codes for programmers. They make your code look cool and smart, but they can also mess it up if you use them wrong. Don’t just copy-paste them from a book or a website. Think before you code, and use design patterns only when they make sense. Remember, they are not laws, they are suggestions. And sometimes, they suck.
I have a really hard time remembering the names of the design patterns I use — which is kind of a problem, because the point is to give these a name.
Anyone else in this boat?