I would say it depends on experience with patterns. When you first learn them, trying to design with patterns can easily bias you to implementing one when perhaps the problem could be solved more simply. And usually patterns have some variation in how they can be implemented. For example, Producer/Consumer should use different concurrency controls for different usage situations.
The Shiny Problem
When you have a shiny new hammer, all problems look like nails.
I definitely do not believe that using pre-packaged design patterns like lego blocks to build software is a good idea. I think this often ends up with over-engineered and hard-to-maintain software. Largely because it leads you to focus on the technical aspects of the implementation, which are generally less important than making sure that your user's problem is really solved.
I usually find that implementing a solution in the simplest way I know how is the best choice. That includes choosing a path which makes bad states and edge cases unlikely or impossible. Sometime during/after the implementation, I might realize that I ended up using a design pattern. And then comparing what I did to the pattern might help to refine the solution even further.
In the longer term, you might start to recognize some implementation problems as fitting a design pattern very well. But do not put too much stock in it. Sometimes, it only takes a quick email from a customer to change requirements. If you get stuck on the idea of implementing the pattern, your brain will filter out contrary details. I have made this mistake before, which resulted in not delivering what the customer really wanted.
And lastly, one thing that patterns can do is allow you to efficiently communicate your solutions to others. Saying Producer/Consumer is a lot faster than describing how that works. However, this depends on the other party being familiar with the pattern. When the other party is not familiar with it, then it ends up taking longer to explain it. Because now there are two new ideas they have to conceptualize: 1) the pattern and 2) your software's usage of it to solve the problem. Whereas they just wanted to know 1) how your software solves the problem. I usually ask first if they are aware of the pattern I want to mention. If not, I proceed to explain the solution first, then point out how the pattern fits in.
Anyway, I really like the idea of design patterns, but I find them difficult to use prescriptively. It's more like an animal classification... it is not easy to predict what classifications you will see when walking through strange woods. But once you get back to camp, you can tell everyone about the Danaus plexippus (monarch butterfly) that you did observe.
Java Web Developer with a passion for Spring and cloud computing. Know a thing or two about AWS. Trying to learn NodeJS lately with the help of TypeScript.
Thank you for the reply, I think it was longer than my post! hahaha
Yeah, you are right, with the ever changing environment we live in as developers, we generally don't have much time to think about the best way to implement right off the bat and if we try to apply patterns in everything it ends getting in way more than helping. I will follow your suggestion in trying to make design patterns as part of my code improvement stage, I already do that with the creational patterns, that are the ones I'm more used to like I said in the text.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would say it depends on experience with patterns. When you first learn them, trying to design with patterns can easily bias you to implementing one when perhaps the problem could be solved more simply. And usually patterns have some variation in how they can be implemented. For example, Producer/Consumer should use different concurrency controls for different usage situations.
I definitely do not believe that using pre-packaged design patterns like lego blocks to build software is a good idea. I think this often ends up with over-engineered and hard-to-maintain software. Largely because it leads you to focus on the technical aspects of the implementation, which are generally less important than making sure that your user's problem is really solved.
I usually find that implementing a solution in the simplest way I know how is the best choice. That includes choosing a path which makes bad states and edge cases unlikely or impossible. Sometime during/after the implementation, I might realize that I ended up using a design pattern. And then comparing what I did to the pattern might help to refine the solution even further.
In the longer term, you might start to recognize some implementation problems as fitting a design pattern very well. But do not put too much stock in it. Sometimes, it only takes a quick email from a customer to change requirements. If you get stuck on the idea of implementing the pattern, your brain will filter out contrary details. I have made this mistake before, which resulted in not delivering what the customer really wanted.
And lastly, one thing that patterns can do is allow you to efficiently communicate your solutions to others. Saying Producer/Consumer is a lot faster than describing how that works. However, this depends on the other party being familiar with the pattern. When the other party is not familiar with it, then it ends up taking longer to explain it. Because now there are two new ideas they have to conceptualize: 1) the pattern and 2) your software's usage of it to solve the problem. Whereas they just wanted to know 1) how your software solves the problem. I usually ask first if they are aware of the pattern I want to mention. If not, I proceed to explain the solution first, then point out how the pattern fits in.
Anyway, I really like the idea of design patterns, but I find them difficult to use prescriptively. It's more like an animal classification... it is not easy to predict what classifications you will see when walking through strange woods. But once you get back to camp, you can tell everyone about the Danaus plexippus (monarch butterfly) that you did observe.
Thank you for the reply, I think it was longer than my post! hahaha
Yeah, you are right, with the ever changing environment we live in as developers, we generally don't have much time to think about the best way to implement right off the bat and if we try to apply patterns in everything it ends getting in way more than helping. I will follow your suggestion in trying to make design patterns as part of my code improvement stage, I already do that with the creational patterns, that are the ones I'm more used to like I said in the text.