Patterns: Powerful and Dangerous
by Tim O'Brien
Most programmers follow a similar development path. Introductory material leads to more advanced material, a new programmer might start with learning types and conditional statements, then move on to data structures and algorithms. Eventually most programmers are confronted with Design Patterns, the promise - the promise that "everything is a pattern". And, while Patterns are important, they are not a panacea. In fact, when I sense that people are trying to over apply patterns it reminds of my 15-month old daughter learning shapes. She picks up a square peg and tries to jam it into a round hole, when this doesn't work she gets a little frustrated, and when that doesn't work she redoubles her effort until her attention drifts to something else (like Curious George).
Design Patterns: Powerful, Essential, (and Dangerous)
"We use patterns" is not a shibboleth for success. When a new programmer starts to get interested in patterns, I tend to have a mixed reaction. On the one hand, patterns are an important part of engineering any large system. If you are implementing anything with more than a few thousand lines of code, a working knowledge of patterns is a prerequisite; it is convenient to tell someone that this particular system uses an AbstractFactory or the Command pattern. Alternatively, I've also seen a number of systems that either overapplied or abused patterns by applying them when they were not appropriate, confusing one pattern with another, or just getting a pattern wrong. (...umm..someone must have read the book backwards because this is definitely not MVC.)
In my own experience, I ran for design patterns at the same time I was infatuated by UML. In 1999, patterns supplied the language I needed to take that next step to understanding larger systems, and my office walls were plastered with man-sized static structure UML diagrams. Patterns + UML made it easy to visualize and communicate, but I found that approaching problems with patterns in mind tended to affect the solution. Subconciously, I would think of some way to apply a "pattern" to the problem. (And, then, all of a sudden everything was an AbstractFactory...) Patterns appeal to the idea that one can escape the day to day frustrations of programming by capturing abstract structures which can be universally applied. All the books about patterns appeal to this ideal, and they tend to play upon Patterns as a pancea or Patterns as a common language. (Patterns as Esperanto.)
|Maybe one way to sum this up would be to say that patterns are for coding, not requirements. Patterns are for solving well-known coding problems or "forces" in well-known ways. Patterns should lead to code becoming easier to maintain, not less.|
|Patterns are not building blocks of solutions, they are characteristics of problems. You do not implement them; you *recognize* them.|
Try Golden Hammer,
Patterns are cool
Patterns are intended for use as "prefabricated" solutions (or suggestions to solutions) to commonly recurring problems in software development. They promote good, well thought out "design" and generally result in good, solid object oriented code. Patterns are an *engineering* approach to articulating solutions "templates" to these common problems. Nothing more, nothing less.