Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Conclusion
When I first encountered the buzz surrounding Design Patterns, I was rather put off by it. The more I heard about it, the more it seemed to be just taking stuff that was obvious to me as an experienced programmer and codifying it with a complex series of definitions, sometimes with debate-inspiring subtleties (like the discussion of whether MouseAdapter is really an Adapter). It struck me as sort of like Martha Stewart for programmers: taking everyday tasks and making them more elaborate and difficult.
But then I got a chance to read the book, and the comments of Steven John Metsker, and discovered that the best use of design patterns isn't to provide a set of constraints on software developers. The best use is to provide a new language that was missing previously: a language for those bits of code that we write every single day, over and over. The book's authors intended them as a way to communicate between designers, but it's just as much a way of communicating with maintainers. That communication is facilitated by providing names to the idioms (read: design patterns) that you know and use every day. You're unlikely to discover any new styles of programming by reading the book, but you'll at least be using the same language to describe your programs.
When the maintainer recognizes a pattern in a piece of code being maintained, the maintainer grasps a bit more about the code. The maintainer taps into a wealth of background material: personal experience as well as what's read in textbooks like Design Patterns. That background can clue you in to potential pitfalls, limitations, and the intended way for the code to evolve. Or, if the code fails to completely match the patterns, you have a guide to what needs to be added to gain the benefits of that pattern.
The original Design Patterns book is good for reference, but it's a little tricky to learn from. It's good for confirming hypotheses (checking whether a piece of code does in fact match a pattern), but it's not exactly a good beach read. My personal recommendation is the Design Patterns Java Workbook by Steven John Metsker (Addison-Wesley, 2002, ISBN 0-201-74397-3). It's clear, well-written, and full of amusing examples. It also accomplishes one of the trickiest things in understanding design patterns: finding an order in which to present them. The design patterns are all interrelated, and there's no perfect order, but this book comes pretty close.
The other advance of the design patterns text is to give you a framework to think about the programming idioms you've discovered that don't yet have a universal name. When you feel that you're writing or reading a piece of code for the nth time, ask yourself:
What's the general pattern of the code?
What's the intent of the pattern?
What's the abstract structure of the classes and methods involved in it (the pattern common to every time you've written it)?
What are the consequences of doing it that way?
How does it relate to other design patterns you've discovered or used?
Then try to come up with a name for it. Use it around the office. Who knows? It might catch on.