Design patterns represent repeatable solutions to common problems found in designing object oriented systems.  They represent optimal (though not perfect) ways of arranging classes and objects together and assigning to each class responsibility for instantiating, interacting with, composing other classes and passing messages to each other in order to solve a particular problem faced by developers.  Consider a radiator, such as is found in a car.  You might ignore it for a long time, but if you have a “vintage” automobile, then driving on a hot day in bumper-to-bumper traffic (a radiator’s worst nightmare) you might notice your windshield getting an unscheduled “steam-bath.”  So, you call your favourite mechanic and you get the car to his garage.  Then, having a lot of time on your hands, you finally pay some attention to the unassuming, but very vital piece of equipment that thanklessly cools your car engine day by day.

The radiator is a vital component in your car and is composed of parts which interact to achieve the cooling of your car’s engine.  In the same way, a design pattern represents an arrangement of classes with an assignment of responsibility to each, which represents the way to solve a particular problem. This arrangement is easily recognizable to the initiated and is easily reproducible in other situations.  It is also easy to extend and maintain the pattern by those who understand its inner workings.  Every self-respecting mathematician understands that math problems have patterns which comprise participants that collaborate (quadratic equations have cubes and squares that are solved by factoring, simultaneous equations have two equations, each with two instances of the variables to solve for and geometry problems have lines and angles and are solved with cosines, sines and tangents). The goal of this tutorial is to have every single O-O programmer in the world be initiated into the structure and workings of design-patterns.

Origin of Design Patterns

There are hundreds of design patterns that are broken down broadly into design patterns, concurrency patterns, transactional patterns, web patterns and other categories.  So design patterns are by no means the only category of patterns.  No one is saying that the Gang of Four (GoF) have cornered the pattern market.  For that matter, it should be pointed out that the GoF did not even create these patterns.  They largely existed in O-O systems before.

In 1994, four guys, now all PhDs: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (who died of cancer November 24, 2005) came together in order to write a book that was built on Erich’s PhD thesis.  It was published as “Design Patterns, Elements of Reusable Object-Oriented Software” (Addison-Wesley, ISBN 0-201-63361-2).  On the way to being published, it was presented to several O-O conferences and eventually in book form became known as the “bible” of patterns.  The software development community also affectionately nicknamed these four pioneers the “Gang of Four” or GoF (folks concerned about misguided religious fervor should note the common “o”).  So we have a “Gang” which is responsible for a “bible.”

The GoF patterns represent the core of design patterns.  When you study them and look at other patterns, you see tremendous similarities which make you suspect that you could get by with focusing on the 23 they described.  They might have tweaked them a bit to improve their robustness, but they were pre-existing and the GOF simply documented them.  In fact, a requirement for a pattern being documented was that it already existed in several applications.  What the GoF actually contributed was their methodology for cataloging them, which is impeccable and introduced the well needed thought process required to mull over, digest and ruminate on design patterns in order to make them a part of your vocabulary and incorporate them as the centerpieces of your design efforts.

So the GoF simply did for design patterns what the Bauxite companies did for Aluminum. The Bauxite companies did not make Alumina, but they engineered ways to find it, unearth it, process it, purify it and turn it into Aluminum - a metal that the GoF would have appreciated on (I assume) their trips across continents, since it is used in the instantiation of the structures of Airplanes and Cars due to its lightweight coupled with its tendency to behave very robustly under pressure.  The unfortunate thing is that scientists are usually poor businessmen (literally) and usually lack branding and marketing skills.  I ask myself what the difference between CISCO and what GoF Patterns could have been or still could be?  The answer I come up with is nothing.  In fact, let me be (one of?) the first to predict that there will be GoF certification in the future.  GoF centers will be all over the world, complete with logo and quarterly results.  I know PhD's abhor money.  But after all, the Bauxite companies did not create bauxite either.  And believe me, in Jamaica, when you work for a bauxite company, you do not exactly beg for a living.

As for the other design patterns and other categories of patterns, if you are interested in the hundreds that exist then do not stop here, you are welcome to go explore.  Me, I specialize in GoF.