Two books I have include Design Patterns in their tittles, but neither actually deals with the kind of Design Patterns that GoF deals with. One is Jennifer Tidwell’s Designing Interfaces: Patterns for Effective Interaction Design (O’Reilly). In this book, different UI design patterns are discussed. The general patterns Tidwell examines are those found in everything from human behavior to UI interfaces. They include names like Safe Exploration (a human behavior pattern), One-window Drilldown, (information architecture) and Hub and Spoke (navigation). From the get-go, I don’t think that anyone ran out and bought Jennifer’s book thinking that they were going to be learning about the kinds of Design Patterns found in the Gamma, Helm, Johnson, and Vlissides book.
The second book that is more easily mistaken for GoF-type Design Patterns is Michael Mahemoff’s Ajax Design Patterns (O’Reilly). Subtitled, Creating Web 2.0 Sites with Programming and Usability Patterns, the Ajax Design Patterns book is not about good OOP and principles for software in general but rather about what the subtitle implies. This is not to say that Mahemoff doesn’t care about good OOP, but rather his emphasis is on Web 2.0 site–the kind of site that Tim O’Reilly envisions. Buried in Appendix C (pg 605), Mahemoff distinguishes his use of design patterns from that of GoF, but it is not the kind of place that most developers are going to look when they pick up a book about Design Patterns. Likewise, Mahemoff uses the inside front and back covers to list the Ajax design patterns. On the one hand, anyone who reads those pattern names is going to know that this book is not about the kinds of design patterns GoF examine. On the other hand, the fact that the patterns are listed there, just like the GoF book, is a sincere form of flattery in the form of imitation. Also, the author had to reply to a 1-star review by an irate reader on Amazon.com. The reply is quite good, but the fact that the title and not the quality of the book is what’s getting blasted should serve as a precautionary tale about using Design Patterns in a programming book’s title.
Mahemoff is quite right in noting that the “original” design pattern book is Christopher Alexander et al’s town planning and architecture patterns book from the 1970s.(In fact in the Foreword to GoF’s DP book, Grady Booch mentions Christopher Alexander’s work.) However, common usage of design patterns in the context of computer programming has come to mean the kinds of patterns GoF talks about. Head First Design Patterns is a good example. No one was disappointed because they were surprised by the meaning of design patterns. Common usages in a given context come to have a specific meaning. In the world of quilt-making, design patterns mean something entirely different than in programming, and so no one is surprised when they get a book called Quilt Design Patterns and find out that there’s nothing about the Creational, Structural, Behavioral Design Patterns. However, in the world of programming, that is exactly what can (and did) happen in the case of Ajax Design Patterns, despite the fact that no less than Ralph Johnson reviewed parts of it.
Quite apart from the book’s title, Mahemoff, does take up the invitation to contribute to design patterns offered up by GoF and he documents a number found in Ajax. While on a different level and with a different specific meaning than that found in GoF book, Mahemoff provides a wider view of design patterns and has what may be the best Ajax book on the market. It would be a shame if his work is diminished by the title, but among some, especially on the higher end, that may happen. Fortunately, the bulk of the reviews are readers who were looking for a good Ajax book and got exactly what they wanted.
The More than one Design Pattern set by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Related posts:
Bill Sanders
I think that any discussion of design patterns and computing, especially with ECMAScript type of languages like ActionScript 3.0, JavaScript 2.0/PHP (or some other Ajax combination) and C#, is valuable for transforming a lot of programmers — this is the crew that was once described as “Non-serious programmers” by a couple of Colgate University professors. These are the programmers who cut their teeth on programming by taking online courses, attending SIG meetings and just by reading and doing. Most likely they went through the process from sequential > procedural > OOP. Upon arriving at OOP, they may have found Design Patterns of the GoF sort. So while they may have started on the wrong foot, with the wrong language and language structure, they have arrived, and there are lots of them. A big percentage of Web sites have been developed by these folks, and they’re beyond the pale of mere “Web Masters.” (Shudder…)
Why is this important? Oddly, while a growing number Web developers have come from non-computer science (CS) backgrounds, the enrollment in CS, as well as other technology-related specializations by college students, has been dropping like a rock. Despite the hysterics by the “anti-immigration” crowd in the US, the US would be screwed were it not for immigrants who have computing skills. However, even with immigration and outsourcing, a large number of technology positions for Internet-related software go begging. As a result, many of those who fill the positions come from the “Non-serious” pool of programmers. Some have degrees in other areas ranging from music to communications, while others have not even gone to college. However, they desperately need these higher level skills and conceptual frameworks in OOP and design patterns.
This is where confusion can set in. In a CS curriculum, Design Patterns generally have one meaning and that’s the one used by GoF. (I checked at MIT and some other places, and where the term ‘design pattern’ comes up in computer languages, so too does GoF or one of their patterns.) However, for non-CS types, Design Patterns don’t mean jack. All too often, they buy into the misconceptions about design patterns thereby not only missing out on the good OOP practices fundamentally embedded in design patterns but the larger community of discussions about them.
Anyway, as long as design patterns aren’t relegated to the granularity of algorithms or mere expressions, I suppose a wider OOP discussion should be considered with design patterns and ECMAScript languages.