What are the best resources for design patterns and their uses?

Question

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.

Answer 1

I think the best web resource containing information about patterns and refactoring - http://sourcemaking.com

Answer 2

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.

Answer 3

http://www.dofactory.com/Patterns/Patterns.aspx

Answer 4

There are lots of different 'pattern' families out there, but taking your question its broadest terms...

I'd recommend:

• Jim Coplien's Organisational Patterns
• The Hillside Group wiki
• Kevlin Henney's site has plenty of excellent links & papers

Offline (my favourites):

• Fowler's Patterns of Enterprise Architecture
• Feather's Working Effectively with Legacy Code

Offline (popular):

• GoF Design Patterns
• Fowler's Refactoring: Improving the Design of Existing Code

Answer 5

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.

Answer 6

Everyone's using patterns all the time. They just might not know it. Even a simple thing like 'iterate over a list' is a pattern.

I think the best way to incorporate patterns into your work cycle, is just to use them, and to refer to them by name when discussing them and when commenting your code. Hopefully, this will result in a spread of knowledge.

So, say for example, you've spotted that what your doing is a great fit for Observer. You say to your colleague "Hey, this will be really easy to do if we make this object an Observer, and this object its subject."

Either your colleague will understand right away -- that's patterns saving you time -- or you get to educate them, and next time you mention Observer they'll understand right away.

And at the same time, you're spreading the knowledge, and they'll spot opportunities to use the new patterns they've learned from you. This goes both ways of course. Next time it might be them teaching you a new pattern.

All of this does rely on your colleague not being the type who nods and pretends to understand something when they don't. You do need them to say "Hey, you mentioned Observer, I don't think I know what that is."

Answer 7

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.

Answer 8

I am a big fan of the series and have read many of their books, so I'd recommend Head First Design Patterns. You can read it online via O'Reilly's Safari Bookshelf, but the hard copy comes with a great patterns poster too.

Answer 9

I would go with the Gang of Four's Design Patterns book myself

Answer 10

I agree with these references, but there are not newbie friendly. To quick start learning design patterns the easy way :

Head First : design pattern

Then your can check the more advanced books once you got the big picture (a lot of practical examples ;-))

Answer 11

The use of "pattern" depends to a high degree from

1. the language used
2. goals one like to achive.

Design pattern can be named overrated in languages like C++, Java and the like. They hide the inflexibility introduces with all kinds of typing issues. Here's a link on what pattern "survive" in less restrictive languages: http://norvig.com/design-patterns/

Another example is the aspect oriented programmming, in which with might effort things are "introduced" in a language not "designed" for it.

The philosophy behind the used tools has a big influence also. Just compare let's say average PHP or Visual Basic programs and solutions in Smalltalk, Common Lisp,Haskell and the like.

The syntax elements have a big impact also. You'll see tons of similar loops let's say in C, C++ (iterators) but if you'd look into languags which support for higher order functions you'll just find a few loops.

You then have to see which way people do access programming, bottom up or top down, piecemeal growth or building pyramides, or any other individual preferences

I suggest reading the mentioned link, and then check implementations in "different" languages....

Regards Friedrich

Answer 12

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!