The Patterns Trap
One often sees these days software recruitment adds for "senior" developers which include phrases such as "must be familiar with design patterns". Thinking that I should at least be conversant with this catchphrase, I have on a few occasions sat down with a "Patterns" book. I never lasted more than twenty minutes before starting to doze off. (After writing the last sentence, I dropped around to the local Chapters to try again. Different book, same topic, same reaction!)
I have rearely seen so much prose expended on describing what should be obvious. In my opinion, "patterns", as they are variously defined, are simply the artifacts of good design practice. They do not represent anything fundamentally original in software engineering technique. They are little more than a reformulation, in the object-oriented idiom, of principals of modularity, coupling and cohesion.
I think Patterns books are well suited for third or fourth year Computer Science courses in software engineering, to encourage novice programmers to think about solutions to programming problems at a more abstracted, generalized level. Any working programmer with more than a few years experience on reasonably challenging projects should approach problems in this way as a matter of habit.
My concern with the overly formalized descriptions of "Patterns" found in these books is much the same as that with rigid documentation standards. Consider the following scenario: A novice programmer reports to his team leader that he has utilized the familiar "foobar gizmo" pattern when coding such and such a module. Since the foobar gizmo pattern is well documented already, there seems to be no need to provide summary documentation of the module architecture. But in his enthusiasm to demonstrate that he is becoming a good engineer familiar with the latest trends, he had rushed off to match the problem with one of the patterns, without spending enough time thinking deeply about the problem. Sure, there are some "minor" aspects of the problem which don't appear in the pattern description, but, well, that can be handled by these few "modifications" here and there. A few weeks later, the requirements or overall system architecture are modified. Our programmer must do some tweaking, driven now by a looming milestone on the schedule. The resulting code works, but its relationship to the original pattern is now tenuous. A few months later, a new team member is assigned to a task affecting the module in question. He sees the reference to the foobar pattern, strains with no success to see it reflected in the actual code, and becomes cynical about the whole process.