1. I'm not the biggest fan of the Gang of Four book, but it's a reasonable place to start, especially if you're doing C++, Java or C#. But IMHO, the best way

1. I'm not the biggest fan of the Gang of Four book, but it's a reasonable place to start, especially if you're doing C++, Java or C#. But IMHO, the best way to learn design patterns is to examine code which uses one of the patterns. In the mid-90s I was working on a big Java project and one of my co-workers had boarded the design patterns train. He went out of his way to code in a way that was very obviously pattern-oriented. I did have to do some reverse work to try to figure out how particular patterns were better than other patterns or better than no pattern at all, but it absolutely made it easier for us to talk about the code. Sadly, I think there's no substitute for "examine other people's code." Software documentation has fallen out of style as the young kids now believe every line of code they generate is a "golden pearl of wisdom, exquisitely obvious to all but the most dense. Oh? You don't understand it? You must be dense." 2. How do you know when to use a loop? Or an if...then construction? It might be hard to remember, but there was a time when you didn't know what a for() loop was. Then maybe you watched some videos or read some books and it made sense and you wrote a bunch of code with loops and then it was second nature, subsumed into the grey matter behind your eyeballs. I think the same thing happens with design patterns, but they're "bigger" than simple control structures, so you need a bit more training. Also, don't be afraid to use only a few of them. They're supposed to help you, not make you feel like you're an idiot 'cause you haven't encountered a situation where you can use them all. They're not Pokemon. You don't have to get them all. 3. Sadly, I think it's just experience. Again. Read other people's code. Read the comments and issues to see if using the pattern made it easier or harder for other people. Also... I was just looking at this and I think Dick Gabriel, as usual, has cogent comments to offer: http://wiki.c2.com/?PatternsAreNotTheLesserOfTwoEvils http://wiki.c2.com/?PatternsAreNotTheLesserOfTwoEvils