how to select design patterns
-
It is mostly about experience. Design patterns get their name from their repetitive nature. When you have seen one type of problem often enough you can tell when a similar solution would apply. Patterns can be at very different levels of the software architecture though. A pattern like the Party pattern is pretty high level and implies data models. A pattern like Observer can be much lower level and might only apply to an event on a single control like a button click or it could be very high level and be applied to a message queue in an enterprise service bus. Be careful about patterns. They can be a lot like fads. When Microsoft released the MVC framework tons of people decided that they had to shove all their projects into that pattern. But if you only ever have one view and that view has to re-implement a lot of the business rules that would also go in the model (client side validators in the view and further validation in the domain objects), you aren't buying yourself much.
-
anoop_m83 wrote:
how to select design patterns according to project
Obiously, its is based on the requirement. At the time of design, one should decide, what pattern best suits for the requirement. At some point, tailoring of an existing pattern ,might be required also.
Cheers!! Brij Visit my Blog: http://brijbhushan.net
Check my latest Article :ViewState - Various ways to reduce performance overhead -
Find a design patterns book/website, implement them, and understand why and when they are used. Then decide if any are applicable to your project given your requirements. Each design pattern is a solution to a problem, not a solution looking for a problem. The original Gang of Four (GoF) patterns each had a specific use in mind. The idea behind the book was that if you had a problem there is probably some commonly used solution which can be applied without needing to re-invent the wheel. A second advantage is that the patterns were given names which developers can use as a kind of shorthand e.g. "I'll us a singleton class" as opposed to "I'll need to write a class to make sure that only one instance of it exists". The problem is design patterns have become the latest thing, so everyone wants to say they use design patterns. Additionally there has been a design pattern explosion too (negating the "shorthand" effect). That's not to say there is anything wrong with the original research, just the way it has been taken up by the dev community.
-
Start off by working out what you actually want your project to do, and how you want it to work. Once you know that, you need to break the application down into smaller areas and start thinking about how to compartmentalize the different aspects of the app. Don't get hung up on designing for patterns; let it come naturally.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads