In the last post we learned about the bridge
pattern and its
pedigree from the envelope/letter pattern of Coplien (and probably other
sources, I’m just not an expert enough to know about them all!) Now let’s
compare it to some other patterns and examine the differences and
similarities. It often turns out that the rationale behind implementing some
pattern is crucial, even when the different patterns themselves might look
substantially the same in code.
Unless you’ve been living under a rock, you know how important and influential
the GoF Design Patterns book
book has been. If you have been living among the rocks, do yourself
a favor and get a copy of the book. It’s considered prerequisite reading for
software developers these days. Interviewers love to hear you mention one or
two of these patterns by name (in the appropriate context, of course), and
just thinking about design in this way will make you a better programmer.
Software design patterns have gone from something of a phenomenon to requisite
knowledge for any competent programmer. Their history is fascinating, though,
and rooted in abstractions people noticed after writing and looking at lots and
lots of code. Smart people figured out common elements, and then were able to
describe them eloquently to the rest of us. Let’s have a look at a few
important patterns, including some history.