How will you decide, which design pattern to use?

Thanks to Abhishek for asking this questions – “We do have many design patterns and some of them are very alike, how shall I decide which one to use?”

Yes, indeed, we have many design patterns. If we try to fit one design pattern (among many other design patterns) to our problem statement, instead of fitting problem statement into design pattern, then we will always be confused which one to use.

Actually, we are confused, because we are thinking about design pattern, as soon as we read the problem statement, we start thinking, oh what design pattern shall I put to solve this problem. This is a wrong approach. If you want to follow good engineering practices, then start following software engineering principles in their defined order. 

First, understand the requirement through requirement engineering process (through use case diagrams, activity diagrams and most crucial model the requirement), then convert requirement model into high-level design (understand in and out of problem statement), after that you will be in a position to think about which design pattern(for your low level design) apply to solve the problem.

Remember one golden rule, it is the requirement itself who will answer your question, of what design pattern? There is a very thin line between some of the core design patterns, that thin line will be visible to you once you model your requirement, and ask many “whys”.

Each design pattern has problem statements defined in their documentation. If you look at them from a very high level, then you will end up having doubts in your head, like - the other one was also solving similar kind of issues. To remove this confusion, you have to start practicing modeling the design. Pick one requirement, model it correctly, and apply patterns. 

After practicing a few weeks, you will find the changes in yourself. Try to participate in different online quiz on design pattern, and see your score and improve it, after doing all that you will agree with me that the requirement itself will tell you what design pattern to apply if you model it correctly. Avoid fitting patterns into your problems, treat patterns as tools, model your requirement, and see which tool can help you with your problem statement. Requirement modeling is an engineering topic altogether. 

Let me tell you one example – suppose you are looking for some medicine due to some medical illness. Of course, there are lots of medicines available in the market to fit similar illness problems, but sometimes the difference between those medicines is very thin. Wrong approach is to pick some medicine X based on high-level analysis. Or say trying to put a solution into the problem statement. The right approach is to diagnose your illness, understand the problem completely. Then you will understand the thin line difference between those medicines. Then apply the solution (or say putting your problem into solution space). Maybe this is not a very good example to explain the concept, but I hope you understand the approach of selecting solutions.

Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.