Here, I will be trying to put my understanding about the design patterns.
Though everyone & me also, read a lot about the design patterns around, so I don't think that I need much to express here.
But I would like to say that - While implementing any requirement or while designing you application or while creating the structure for your application, never ever block your thoughts for any design pattern. Once you stick to a particular design pattern, it is good to streamline the coding style.
But it causes many issues later & you can streamline your coding style following other processes but not putting any constraints on your application structure. Just develop the application with open mind & use best possible solution for that particular issue in hand.
Break the whole requirement into smaller atomic requirements for which you can develop a module, follow the best suitable process to develop a good module, then you can start assembling or integrating them in the application as they complete. And this way you find that every part will fit into the place perfectly without causing much changes & will save many tensed hours of your work. Then re-visit & check what design pattern you followed or you can give a new name to the pattern followed in your application. You can think that I am against Design Patterns here, but that's not the case at all. I am against those self declared Tech Geeks, Architects, Managers, etc who don't give enough efforts in understanding the problem details & the implementation difficulties but simply toss the Design Pattern names to use to get praise like these people know a lot but believe me that such people are the root cause of all the future issues during implementations.
So don't put much efforts on deciding on a design pattern to follow in the application coding & that too in the start. In today's agile world many things change during your coding & by deciding on the design pattern in the start you are putting the constraints on the kind of coding to be done. And I have observed such decision causes issues later during coding & specially when client changes some requirement & now that requirement doesn't fit into the concept of the design pattern being used. And as per my understanding deciding the design pattern in the start of application development doesn't solve the issues in hand, but analysing the requirements deeply, breaking the requirements in individual atomic pieces & doing the best possible coding for that issue do.
So my suggestion is - Concentrate on the understanding of the requirements & their best possible solution first. And in each design patterns they are not doing much different, just changing some pieces here & there.
Let the design pattern come to your coding & implementation code, not enforce it or artificially include it.
And if I feel to share something about any design pattern then I will be putting that here. Though you can get much information from other online resources.
Methodologies & Design Patterns
Though everyone & me also, read a lot about the design patterns around, so I don't think that I need much to express here.
But I would like to say that - While implementing any requirement or while designing you application or while creating the structure for your application, never ever block your thoughts for any design pattern. Once you stick to a particular design pattern, it is good to streamline the coding style.
But it causes many issues later & you can streamline your coding style following other processes but not putting any constraints on your application structure. Just develop the application with open mind & use best possible solution for that particular issue in hand.
Break the whole requirement into smaller atomic requirements for which you can develop a module, follow the best suitable process to develop a good module, then you can start assembling or integrating them in the application as they complete. And this way you find that every part will fit into the place perfectly without causing much changes & will save many tensed hours of your work. Then re-visit & check what design pattern you followed or you can give a new name to the pattern followed in your application. You can think that I am against Design Patterns here, but that's not the case at all. I am against those self declared Tech Geeks, Architects, Managers, etc who don't give enough efforts in understanding the problem details & the implementation difficulties but simply toss the Design Pattern names to use to get praise like these people know a lot but believe me that such people are the root cause of all the future issues during implementations.
So don't put much efforts on deciding on a design pattern to follow in the application coding & that too in the start. In today's agile world many things change during your coding & by deciding on the design pattern in the start you are putting the constraints on the kind of coding to be done. And I have observed such decision causes issues later during coding & specially when client changes some requirement & now that requirement doesn't fit into the concept of the design pattern being used. And as per my understanding deciding the design pattern in the start of application development doesn't solve the issues in hand, but analysing the requirements deeply, breaking the requirements in individual atomic pieces & doing the best possible coding for that issue do.
So my suggestion is - Concentrate on the understanding of the requirements & their best possible solution first. And in each design patterns they are not doing much different, just changing some pieces here & there.
Let the design pattern come to your coding & implementation code, not enforce it or artificially include it.
And if I feel to share something about any design pattern then I will be putting that here. Though you can get much information from other online resources.
Methodologies & Design Patterns
Till no intelligent person says it, people dont take it. I have been saying the same for past few years but managers or architects or team leaders continue to follow the design patterns blindly.
Learn Builder Design Pattern. This is the 5th post in a series on… | by Neeraj Kushwaha | May, 2022 | Medium
What is the difference between Builder Design pattern and Factory Design pattern? - Stack Overflow
What is the difference between Builder Design pattern and Factory Design pattern? - Stack Overflow