I've learned the hard way over the past several years that when you see the Design Patterns book show up on a junior developer's desk, you need to watch them very, very carefully for the next six months. Otherwise, you'll turn around one morning and discover a set of Builder pattern classes, flanked by Facades, sitting in the middle of what should have been a simple object model. Something about that book tickles an urge to build. It is like a box full of shiny power tools, all crying "play with me! use me!" Patterns start popping up like warts, complicating otherwise simple regions of code. And unlike ordinary messy code, this is messiness at the structural level. It costs a lot more to undo. And yes, this can even happen in Perl-based systems.

I really do like the book. It lays out a taxonomy of reusable design and implementation elements that I've reached for, judiciously, many times. Lots of problems are solved quite flexibly using a Strategy pattern. Template methods can reduce coupling. In good hands, design patterns are a powerful tool. But the chaos in that book's wake caused by immature developers can be enormous.

So my recommendation is that if you see Design Patterns appear on someone's desk, and you're not confident in their judgement, start checking in with them more often. Ask them how they like the book, and where they're seeing opportunities to use design patterns. Then talk them out of half of those "opportunities". Your code base will thank you.

And if you're not sure you're ready for the book, I say go for it. It's a great book. Just watch yourself. If you feel yourself making excuses for going out of your way to use a design pattern, stop, take a deep breath, and ask someone you trust for advice.