This. One of my greatest fears is will end up suffering from "design patternitis". I've had situations where the first solution I thought was to use some pattern, but later ended up not implementing it due to the impact on both performance or code complexity. Nevertheless, knowing the pattern helped me reach a better solution, so there's that.
I think that if you go the other way around is better. Work your problem, and if in the end the solution ressemble a common pattern then you have a guideline how to implement it.
Your business logic is important, not the patterns.
Yes, I completely agree with you :) I was just talking about my own experience. I usually end up doing what you said, but it is quite common for me to easily recognize a pattern use case before starting any kind of implementation, and hence my fear.
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.
Just a reminder, "most used" does not mean that they are used correctly, or they are the best solution :D
This. One of my greatest fears is will end up suffering from "design patternitis". I've had situations where the first solution I thought was to use some pattern, but later ended up not implementing it due to the impact on both performance or code complexity. Nevertheless, knowing the pattern helped me reach a better solution, so there's that.
Relevant link: jono.woaf.net/design-patterns/
I think that if you go the other way around is better. Work your problem, and if in the end the solution ressemble a common pattern then you have a guideline how to implement it.
Your business logic is important, not the patterns.
Yes, I completely agree with you :) I was just talking about my own experience. I usually end up doing what you said, but it is quite common for me to easily recognize a pattern use case before starting any kind of implementation, and hence my fear.