This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Patterns are common solutions to common problems. It's good to be familiar enough with them to recognize when you have one of those problems. Then you can consult the pattern and see if the solution fits. Some times it happens the other way. You don't recognize the problem but you recognize your code is starting to look like one of the solutions. Then you might consult the pattern and see if there is anything you haven't thought of yet. If the pattern looks appropriate, you might rename and restructure your code to look more like the pattern. That will help future readers spot it and identify what you're doing at a higher level. There's even a whole book called Refactoring to Patterns that might be a great read right now.
When I first became aware of the Gang of Four book, one of my colleagues breathlessly told me he had built reference implementations of all of them. This turned out to be quite useless except for making him read the book carefully. You almost never apply the solutions exactly as they are in the book, and they'll almost always require some customization and translation into whatever problem and language you have.
The last thing you want to do is get excited about the latest pattern you read and go hunting for a place to apply it. It's common to try to hammer a pattern into a hole where it doesn't fit. I'm probably guilty of having a few favorites I use too often; I try to keep that in mind and stop before I abuse something.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
isn't targeted towards an audience that is new to design patterns. A good understanding of the patterns he references and the process of Refactoring is assumed.
Often people dive head long into patterns before developing a good understanding of The Principles of OOD on which Patterns are ultimately based on. Mastery of the principles of OOD is far more beneficial then memorizing a number of patterns. However patterns are very useful as a communication tool as they allow the more efficient (higher level of) exchange of ideas in the spoken or written word. Other than that Apply Patterns Gently. [ July 18, 2007: Message edited by: Peer Reynders ]
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com