There are so many design patterns available. How to choose right design pattern?
There are so many design patterns available. I read through all the design patterns and sometimes I feel like more than one design patterns work well for the logic I am coding. Example: I am trying to eliminate multiple if-else and switch statements as it is not scalable. I see the "Chain of responsibility pattern", and "strategy pattern". Both work well for my logic. How can I make a decision of choosing one of the designs for this?
During code review: People share their opinion on using a design pattern, and I sometimes struggle to convince my reviewers of the pattern that I have used in code.
I am open to getting feedback and analyzing different design patterns suggested by reviewers. However, in some situations, I feel more than one design pattern fits for the logic and there is no right or wrong approach.
How to handle this kind of situation?
Discussion
(1 comment)- 6a year agoMeta, Pinterest, Kosei
My (perhaps) contrarian perspective: don't worry about design patterns. Especially in your situation: as a mid-level SWE at Microsoft, you're likely not doing much greenfield projects.
So rather than worry about design patterns, use the existing code as a starting point, and then try to make it better.
If someone suggests a different pattern in code review, your goal shouldn't be to convince them about why your approach is correct. It is to show that you take feedback, and you want to do what is best for the code. Empirically, I've found that these debates are almost never about the theory of the design pattern, it's about the business logic and the existing patterns.
