Hi. I believe that it is more reliable to think about what not to do, rather than thinking in patterns itself. Your second question is a common example of "golden hammer" or "silver bullet" anti pattern. Don't assume that your favorite solution could resolve all the problems.
Maybe a pattern could fit in your proyect or maybe not, but you should not force them. Pherhaps you have a simple project with 2 or 3 classes, and forcing a "abstract factory" or "decorator" result in a overpowered architecture (and confusing, by the way). Sometimes keep it simple is the best.
Now, if you need to start a project with a complex architecture, with many clases and too much interconnection between objects, maybe you should think a bit more and check wich pattern could fit in some situation, but always using the "divide and conquer" strategy first. Always is simplier to resolve many easy problems than a very difficult one. Then, the patterns appear naturally.
Not knowing design patterns is not bad at all, but they could help you a lot. They gives you generic solutions for many common problems
I agree with this line of thinking. The design patterns also sort of find their way to you when you need them most. I personally am not well-versed on design patterns in general, mostly reliant on the pattens I've acquired along the way when I need them, either formally or through natural independent invention.
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.
Hi. I believe that it is more reliable to think about what not to do, rather than thinking in patterns itself. Your second question is a common example of "golden hammer" or "silver bullet" anti pattern. Don't assume that your favorite solution could resolve all the problems.
Maybe a pattern could fit in your proyect or maybe not, but you should not force them. Pherhaps you have a simple project with 2 or 3 classes, and forcing a "abstract factory" or "decorator" result in a overpowered architecture (and confusing, by the way). Sometimes keep it simple is the best.
Now, if you need to start a project with a complex architecture, with many clases and too much interconnection between objects, maybe you should think a bit more and check wich pattern could fit in some situation, but always using the "divide and conquer" strategy first. Always is simplier to resolve many easy problems than a very difficult one. Then, the patterns appear naturally.
Not knowing design patterns is not bad at all, but they could help you a lot. They gives you generic solutions for many common problems
I agree with this line of thinking. The design patterns also sort of find their way to you when you need them most. I personally am not well-versed on design patterns in general, mostly reliant on the pattens I've acquired along the way when I need them, either formally or through natural independent invention.