Possible Duplicate:
How do you know when to use design patterns?
How can I understand/take decision about "When to use what Design Pattern"?
What are the factors to observe while taking decisions about using an appropriate design pattern in an appropriate place?
Generally, if you're doing it right, there's a pattern for it. You just might now know you're using it.
If you're doing it wrong, there's an anti-pattern for it. But you definitely don't know you're using it.
All well-defined patterns have background, context and the problem solved by the pattern.
The whole point of a pattern is to tell you when it's appropriate.
Check out the excellent book "Emergent Design: The Evolutionary Nature of Professional Software Development". It shows you how we end up at design patterns, and will give you good instruction on architecting your code.
You shouldn't always set out to make your software fit a design pattern, but if it matches one you use it. In many cases most things you do will have a design pattern that is merely a pattern that was observed from many different software implementations as being common.
For instance if you have a set of classes that all need to be synchronized. Well that works well with the Observer or Publish/Subscribe pattern where one class is the notifier and the other listens for notifications. http://en.wikipedia.org/wiki/Observer_pattern
Or say you want to limit memory use in a game engine then you might create an ObjectPool. http://en.wikipedia.org/wiki/Object_pool
Or maybe you want to simplify a set of objects into a simplr API then use the Facade pattern: http://en.wikipedia.org/wiki/Facade_pattern
Many times just using functional patterns like encapsulation or inheritance are fine. It depends on the problem. In most cases much of what you try to code will be solved in a pattern, but patterns aren't the only way to code. In many cases you start designing or have a need and it becomes a pattern.
Remember patterns originated from observing many types of software problems, it is not the starting point but the reflection of software architecture.
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
Many samples of patterns at dofactory.com: http://www.dofactory.com/Patterns/Patterns.aspx
Python design patterns: http://video.google.com/videoplay?docid=-3035093035748181693
Forcing design patterns is like forcing OO. It should come naturally from needs in the project at hand.
I find that if I am just hacking a program, good use of design patterns is almost impossible, but, if you design your program, then you can look at what you want to do and design patterns start to be seen in your application.
For example, if you see that there is a class that directs the flow of the application then the Controller pattern makes sense.
The other way to use design patterns is to write your program, make it work, then refactor using design patterns. I believe Martin Fowler wrote a book on this subject, but I am not positive on the author.
Either way it helps to know what you want to do to help decide which patterns work best.