Gerard Meszaros on the 15th Anniversary of Design Patterns
Gerard is the author of xUnit Test Patterns: Refactoring Test Code.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Wow, has it been 15 years already?!? How times flies. I cannot recall exactly how I first found out about patterns but I do remember reading drafts of the book via an e-mail list (this was well before Al Gore had invented the Internet). I was working for Bell Northern Research (BNR), the R&D subsidiary of Northern Telecom, building telephone switching software, and I was struck by how many of the patterns appeared in some form or another within our software. We invited Richard Helm to come and teach our software developers about the patterns and later we had Kent Beck in to teach a course on writing patterns. In that course I wrote up the first draft of what was to become Half Object Plus Protocol. Kent encouraged me to submit it to the first Pattern Languages of Programs (PLoP) conference which was announced (I think) at OOPSLA in Portland. That in turn led me to be involved in workshopping early drafts of Martin Fowler's patterns, which were later published in Analysis Patterns. Things came full circle a number of years later when I started documenting common practices in automated unit testing in my own book, xUnit Test Patterns. I was discussing some of these patterns with Joshua Kerievsky at another OOPSLA (Vancouver I believe), and he encouraged Martin to contact me about publishing my book in the Martin Fowler Signature Series. As a result, I've been giving tutorials at various prestigious conferences and training courses at major technology companies. And I can safely say that this all started with Design Patterns, so I guess you could say that Design Patterns changed the course of my career.
Looking back at Design Patterns after 15 years is interesting. Of course, it was just the tip of the iceberg and even back then there were lots of arguments about whether some of the patterns were fundamental patterns or merely language idioms. Many of the examples were based on C++, and some Smalltalkers claimed that they couldn't be patterns if they were language features (like Iterator and Visitor). But they were an important way to start the dialog and establish terminology to describe object-oriented program design. Before DP we didn't really have a way to talk about program design in a language-agnostic way; that is one of the major contributions of patterns.
Like all new ideas, patterns were sometimes misused. Rather than using patterns to describe their program design, some misguided souls set about to put as many patterns as possible into their programs. This often result in highly over-engineered software. Joshua's book tried to address this issue by showing readers how you can introduce patterns incrementally as needed rather than all up front. It illustrated a more agile (as opposed to BDUF - Big Design, Up Front) approach to patterns.
I use patterns a lot while coaching teams on how to develop software more effectively. It still amazes me when I encounter teams that have never heard of either design patterns (the concept) or Design Patterns (the book)! But I guess that's why Design Patterns is still a big seller amongst technical books. On a recent project, I was introducing a bunch of senior ABAPers (SAP developers) to object-oriented design, design patterns and automated unit testing using AbapUnit. Several went out and bought the DP book to learn more about the basic patterns. And they incorporated Composites and Commands into their ABAP design. Those are probably my favorites amongst the 23 patterns in DP. Some, like Flyweight, I don't get much chance to use. Others, like Singleton, cause problems with testability unless you build in mechanisms such as http://xunitpatterns.com/Test-Specific%20Subclass.html#Substitutable%20Singleton.