#DEVDiscuss: Design Patterns
source link: https://dev.to/devteam/devdiscuss-design-patterns-5e02
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
#DevDiscuss (8 Part Series)
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:
- Which design patterns have served you well in your applications?
- Which design patterns have stumped you or failed to meet your expectations for problem solving?
- Do you usually use design patterns purposefully or accidentally?
- Any triumphs, fails, or other stories you'd like to share on this topic?
Top comments (22)
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?
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.
Thread
Thread
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.
Thread
Thread
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:
- Name (1)
- Intent (2): A short description of the design issue addressed.
- Motivation (4): A scenario to illustrate the design problem. I.e. does my design problem match up?
- Applicability (5): The situations in which the design pattern can be applied and how to recognize them. I.e does my context match up?
- Structure (6): An abstract graphical representation of the design pattern. It appears this "early" to establish a baseline representation on which the discussions in the following sections (Participants (7), Collaborations(8), etc.) are based on.
- Consequences (9): The trade-offs made by the pattern. This is right before "Implementation" because if the trade-offs made by the pattern can't be tolerated in your particular context then there is no point in implementing the pattern.
- Implementation (10): Pitfalls, hints, and techniques associated with this pattern. Only now do we worry about the implementation after running the gauntlet of Intent, Motivation, Applicability and Consequences.
- Sample Code (11): Only now does it make sense to look at actual code.
Thread
Thread
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"
CollapseExpand
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).
Thread
Thread
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.
- Do you need to change the behavior of a component at runtime - problem.
- You can use the strategy pattern - idea
- I inject a lambda into a component to do the job - concrete implementation.
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
Thread
Thread
Sure! but logically you can avoid the second bullet point because it doesn't add any valuable information:
- We need to change the behaviour of a component at runtime (problem).
- We inject a lambda into a component to do the job (idea and implementation detail).
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) 😃
CollapseExpand
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! 😁
CollapseExpand
Answers for some of the questions:
- The visitor pattern served me well where the respective problems would look very heard to solve otherwise.
- I've been bitten by the singleton pattern several times, to the point that over time I learned to avoid using it as much as possible.
- I tend to use the design pattern accidentally. i.e. When the problem almost dictates the use of one.
CollapseExpand
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.
CollapseExpand
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).
CollapseExpand
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.
CollapseExpand
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
CollapseExpand
I was just asked this same question 😂
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK