Good Examples in Pattern Literature

Three (sometimes four, often two, rarely one) instances of pattern literature should compete for your attention based on having good explanations of the pattern along with good sample code.  Obviously, since the GoF book is the “bible” and I am writing this tutorial, they both get automatic qualification to the “next round.”

Seriously though, for each pattern-source the explanation of the pattern is rated separately from the rating given to the sample-code which accompanies the explanation.  Out of respect, I translated my own 10 star rating into a color coded rating.  I expect that to other writers who have worked long and hard on their articles/books/videos, this might be a little less jarring than a numeric rating.  Below are the colors and an approximate description of what they signify.  Bear in mind that these are the good examples so even at the most flawed end, the discussions and code sample provided are still pretty useful.

Many good examples were omitted since I gave preference to the books I found easy to read, provided broad coverage for the patterns (not just a selected few) and which consistently rendered the patterns in an accurate, easy to follow way.

I find authors miss the point of particular patterns, some get very clever and jazz it up too much so it becomes unrecognizable and some just get it plain wrong.  Sometimes they nail the explanation and deliver it on a platinum platter while some sample code sections are so downright fantastic that just looking at the code after getting a good theoretical grasp of the pattern will totally cement it in your understanding.  If you do not see a particular source listed, it could mean many things.  It does not mean that I do not think the source is useful.  In one JAVA based book I thought the author’s treatment was just too advanced for beginners and too many shortcuts were taken, especially if you are explaining to a new convert who may not understand the trade-offs being taken.  However, the same book would be excellent for seeing how advanced language features interact with design patterns.

Interface issues

These are Interface issues to pay close attention to when implementing the pattern.  Getting the interfaces right will usually mean that the implementation is as robust and recognizable as originally intended by the GoF since:

The classes which implement the interface are fully interchangeable since they are governed by the interface (or as The Economist would put it “fungible”).

The classes are referred to by the interface they implement and so classes which should not know about each other do not end up referring to each other.

Namespace/Scope/modifier issues

These are issues such as constructors which should be scoped as friend and therefore accessible only within the same assembly. Also, shared private constructors should be accessible within the class only and Classes which should be split into namespaces, etc. Putting the classes together in the right namespace helps the reader who learns from your code or maintains it to understand your intentions more easily.  Placing them in the right assembly can help with portability.  It also helps you to check that only the classes which should “know about each other” actually do.  Many times, there should be one or two classes involved in the delivery of the other classes to the outside world.  As mentioned before, these classes would constitute an active or passive delivery mechanism.

Common mistakes in Pattern Literature / Pitfalls to avoid

These are variations seen in other writers' pattern interpretations that, in my opinion, violate the intent of the pattern or make it less robust.  These can include pedagogical issues which make the explanation harder to absorb.  Sometimes it addresses the issue of writers being too clever and burying the pattern under too many clever demonstrations of knowledge of their chosen language (of which I might be guilty sometimes).  Many times it addresses shortcuts which can prove fatal to the pattern-safety and end up introducing holes in the pattern implementation.