September 24, 2006
In his recent essay, Design Patterns of 1972, Mark-Jason Dominus–a long-time favorite writer of mine from the Perl community–writes:
Had the “Design Patterns” movement been popular in 1960, its goal would have been to train programmers to recognize situations in which the “subroutine” pattern was applicable, and to implement it habitually when necessary. While this would have been a great improvement over not using subroutines at all, it would have been vastly inferior to what really happened, which was that the “subroutine” pattern was codified and embedded into subsequent languages.
He draws this analogy because, he believes, the “Design Patterns” movement, noble in its intent, has weakened programmers by desensitizing them to defects in their tools.
The stance of the “Design Patterns” movement seems to be that it is somehow inevitable that programmers will need to implement Visitors, Abstract Factories, Decorators, and Façades. But these are no more inevitable than the need to implement Subroutine Calls or Object-Oriented Classes in the source language. These patterns should be seen as defects or missing features in Java and C++. The best response to identification of these patterns is to ask what defects in those languages cause the patterns to be necessary, and how the languages might provide better support for solving these kinds of problems.
This isn’t the first time he’s made this point. Several years ago, he offered a presentation on Christopher Alexander, where he asserted that the “Design Patterns” movement has turned out to be less useful for programmers than what Alexander proposed for architects. (To reduce the possibility of misunderstanding, it’s probably best to skip ahead and read slide 9, slide 10, slide 11 and slide 12 first.)
It’s sometimes difficult to envision a programming language embodying what we commonly think of as a pattern, which is why his analogies to the “subroutine pattern” of the 1960’s and the “object pattern” of the 1980’s are so perfect.