Speaking in patterns
In the world of enterprise software development, design patterns
are often touted as a panacea to cure all architecture ills. And
let's face it, as developers we love to use whatever Hot New
Thing all the other cool kids are using.
But what exactly is a design pattern and where do they come
from? In 1977 an architect (a "real" architect - the buildings
kind) called Christopher Alexander wrote a book called A
Pattern Language: Towns, Buildings, Construction which
describes a bunch of recurring elements, or "patterns" in
traditional architecture.
Then in 1994 a group of software engineers, the "Gang of Four",
adapted his central idea of recurring patterns and applied it to
software engineering. They wrote a
book (Design Patterns: Elements of Reusable
Object-Oriented Software) which describes 23 classic software
patterns.
The great and powerful thing about design patterns
is that they give us a shared language to discuss some fairly
abstract ideas and solutions to common problems.
Unfortunately, the term "design pattern" is now used to
describe just about every aspect of software development. Google
"design patterns" and you'll see what I mean.
As professional developers, it's our responsibility
to manage the complexity of the applications we create. Design
patterns can be a useful tool to accomplish this goal, but they can
also be a source of complexity for its own
sake. The trick is knowing which situation is
which.