How do you apply design patterns?

Question

From a bookish perspective, you might say that x design pattern is applicable in y scenario, but I want to dig a little deeper here. So here are my queries:

1. When do you first decide that you'll use design patterns? Do all of you decide upon design patterns before coding?
2. Are there any DPs that you apply after you're done coding (small refactorings)? Do you apply DP while maintaining code?
3. What are the design patterns that are predominantly applied during design?
4. What are the DPs that you apply while tweaking/refactoring code?
5. Are there any hints in code (technical not functional stuff) that suggest that you should apply a DP (like too many ifs, double dispatch, multithreading)? If so, could you name the DPs and their catchpoints?
6. Do you use any Micro-DPs that makes you feel good about the code you've written (even though others hate you for it :p)?

Edit:
I'd like to add that I read DPs through "Head First Design Patterns" and although it's one of the best books to understand the pattern. I don't think I've been able to transition the Pizza examples to real world scenarios.

I think this is one of the most influential books on DP but we can still have a book that may enumerate the various popular business scenarios that demand a particular pattern alongside that pattern. This knowledge is still implicit to a large extent I think. Such a book would be a very nice quick reference don't you think :))

Answer 1

1. It depends how you write the code. If it's a big project I decide before coding, then after I start writing the code, if I notice places where design patterns should be used, I refactor the code.

2. Yes, as mentioned before.

3. in 99.99% of the cases: Factory Pattern, Singleton (Like everyone I use it in many places because is simple to implement, and in practice I tend to remove it while refactoring the code). Then: Object Pool(if I have resources I want to reuse - some of my projects are games and I need a good management of resources), Strategy and Template Method (because they are great for decoupling and serve well the purpose to make the code easy to extend). Then the Adapter is something to use when you have a library you want to use, without relying on it(decoupling).

4. Same as Above, if I didn't use them yet. It works also in the opposite way. If I don't find the reason to use a design pattern I remove it or skip it while writing the code (it happens all the time with singleton and from time to time with factories. Sometime I use a factory which is also a singleton to provide me those which were supposed to be singletons objects; not sure if it's wise thing to do, but it works for me).

5. The only code hint I might think it the number of references you have to a class. You can also use PMD, jDepend and Architecture Rules to spot the places where the classes contains too many dependencies. I'm not sure it this is a coding tip. In the design phase and not only there when you decide to use a design pattern just think to the benefits. I found that Software Design Principles are extremely important to help you understand when and why (not) to use a design pattern, but they are unknown to many programmers who are using design patterns.

6. I'm not sure what do you mean by Micro DP. I'm trying to use DPs only when I find reasons to use them and when the benefits seem to be bigger than the problems. I avoid the overuse because it leads you to loosing time implementing and maintaining factory patterns instead of real software.