When should developers read and learn about design patterns?

I want to know when should developers r开发者_高级运维ead and learn about design patterns? Is it in junior, senior, or beyond senior level?

This question is very fuzzy one for me.

---

Early on, you should have a passive knowledge of design patterns. That is, you should know about the most common design patterns that they exist, but you should not try to use them actively. Since most design patterns have to do with class design, you should have a comprehension of classes and program structure before you learn design patterns.

The danger when learning design pattern is that you want to use them actively, even if they are not the right tool for the job. If all you have is a hammer, everything looks like a nail. Postpone the usage of design patterns until you hit a problem which you recognize from a design pattern.

---

I'd say that you can start reading about them once you've grasped the concepts of object oriented programming.

Head First Design Patterns is a great first book for learning about design patterns.

---

I dont think it will do any harm for a junior to start learning the basics around design patterns. Maybe at that level the knowledge should be passed to them by the senoirs developers there, where hopefully they can provide real world examples based on how those patterns have been implemented within their company.

To follow that up, there are some good books out there like Head First Design Patterns, and as they become more experienced they might want to persue the subjects in more detail.

Personally I'm really getting into using the Model-View-ViewModel (MVVM) Pattern which lends itself nicely within the .NET 4.0 environment.

---

I actually find the book dangerous in the hands of junior developers.. Leads to over and misuse of patterns, and the general tendency to run around with a hammer looking for nails. It's a book full of solutions, and if you're not intimately familiar with the problems.. then things can go sideways.

If it were up to me, I'd prefer folks to write lots of code. Just do it. Write code. Make a mess, feel pain, fix it.. Design patterns is handy later on when you need a vocabulary for expressing solutions to team-mates.

Also, I think Refactoring ought to be on everyone's desk way before Design Patterns. It's much more pragmatic.

Just me, though.