Agree with Mark. Using design patterns just for the sake of using design patterns will most likely end up in an over-engineered system. You have to have a deep understanding of the requirements and the circumstances around it before you even use it. You don't have to code everything with a design pattern. If you're just learning design patterns, I suggest you build a personal project - say a web framework or something, but don't do it yet in a production setup if you're just starting. Proper usage of design patterns comes with experience really...

On the one hand, design patterns are sort of meant as copy-paste solutions.

On the other hand, if you're just applying them based on a flowchart, I think you're going to have a bad time.

You have to actually understand what problem the pattern solves and what the downside is. Almost always there is at least added indirection, but probably other difficulties.

There are some exceptions. For example, you probably need something like Adapter if the interface you have does not match the interface you need. Visitor should be used if 1) you have a number of connected objects and 2) you have a number of operations on all of those objects and 3) you want to be able to add operations without changing the objects code and vice versa. Despite the list, it's frequently misused.

But for others it's not so simple. Every object needs to be constructed, but if you make factories for all of them, you're just going to double your code and increase complexity while gaining nothing. And everyone likes performance, but using Flyweight should not be done lightly, because introducing hard-to-find bugs is very likely.

I'm afraid the best way is to read a somewhat long description of the patterns, what problems they solve, their pros and cons, and some examples. They're not going to make your life better if you only have flowchart-depth understanding.

Maybe I'm being too harsh though, comments are welcome.