When it comes to the use of design patterns, I am guessing there are three types of shops. Those who wouldn't know a pattern if it hit them in the face - these usually prefer the Ctrl-C / Ctrl-V approach to code-reuse. Those who spend hours a day searching their legacy code in hopes of implementing one more great pattern - these usually spend more time refactoring the code of simple programs than would ever be spent in a hundred years of maintenance. And finally, those who walk the middle path using patterns when they make sense, and coding whatever comes first for minimally exposed code.
I'm wondering if anyone has locked down a good approach to a balanced incorporation of pattern use in the software development life cycle. Also, what is the best resource on the Web for patterns, their motivating factors, and their proper use?
Thanks.
The definition and original answer is the origin of the concept, in Design patterns. This book deals with the concept at a very theortical level, rather than the management speak that has infiltrated the area. Their view is that design patterns are just names for common idioms; they enumerate some and justify their positions.
They avoid the "What design pattern should I use" type of question, instead dealing with problem as "Am I naturally stepping into a well known area? If so, can others experience help me?". Design patterns, to me, are not like prefab components you glue together to make a solution. They are just guidance repositories for when you come across a situation similar to one others have countered, and give names to allow people to refer to the general situations in conversation.
There are lots of different 'pattern' families out there, but taking your question its broadest terms...
I'd recommend:
Offline (my favourites):
Offline (popular):
I would go with the Gang of Four's Design Patterns book myself
Good usage of patterns depends on knowledge and experience; there's no formula to it. A good thing to do is have someone who is experienced at applying patterns judiciously to regularly review the code of everyone else in the team to make sure they're not overusing or underusing design patterns. They're not pre-baked recipes - they need skill to apply effectively and that has to be learned.
My first and best exposure to design patterns was the Portland Pattern Repository.
I couldn't agree more with the comment above. I use design patterns where I can but always rely on the rest of my team to truly understand the benefits of a particular pattern. Otherwise you end up with ugly code and a lightweight wrapper that somewhat resembles the pattern.
As an aside http://www.developer.com has a few articles a month that pertain to design patterns and their applications. Good luck!
Design patterns are funny in that you only know where to use a pattern when you fully understand the applicable pattern. Things like Strategy, Observer, Iterator you can, aftera little practice, use without thinking too hard. If you're in C# you use the Iterator all the time (IEnumerable...) without thinking of it as a pattern.
In my opinion, these simple patterns are the best patterns. You've already got a job to do, and trying to shoehorn your problem into one pattern after another when it doesn't quite fit is a waste of your time, and results in bad code.
My advice is to look at the uml diagrams for a pattern, and if it's fairly simple, then try and learn it well enough that you can recall it later. A pattern with a simpler contract is likely to be more useful more often.