Each of the patterns in this tutorial has the following structure.  A complete list of my articles can be found here:
http://aspalliance.com/author.aspx?uId=59827

Name of Pattern 

P+ P- E A R D M+ M- S+ S-

The subscripts which appear at the end of the name indicate how the pattern is affected by other issues.  Knowing this helps us to compensate for the deficiencies or make use of the advantages.  Below are the meanings to each of they symbols.

P+: Helps the code to perform faster.

P-: If used unwisely, the pattern may slow down the code.

E :  Helps to create code that is maintainable in an Extensible way (adding functionality).

A :  Helps to create code that is maintainable in an Adaptable way (Changing functionality).

R : Aids in code reuse (several applications will be able to use it as a library).

D : Allows you divide up tasks based on team member strengths.

M+: Helps with efficient memory management.

M- : If used unwisely, the pattern may cause improper memory usage.

S+: Naturally helps to improve application security.

S-: If used improperly, the pattern may compromise application security.

Degree of Difficulty (1 to 10)

1 is least difficult, meaning that a bright person could read the abstract once, glance at the sample code for the pattern and understand what is going on immediately.  It would still suit that reader to glance at the “Common Pitfalls …” section.

10 is most difficult; the average person should expect to read the pattern 3 or 4 times (from several writers’ perspectives) before they really get it.

Structural Complexity (1 to 10)

This speaks to how much bulk the pattern adds to the code in terms of the extra classes and interfaces which are added to the solution to make the pattern work properly.

At first, the reader may confuse having “lots to learn” with being “hard to understand” and so these two ratings are done separately.  For example, Abstract Factory is a very straightforward pattern and is easy to understand.  However, it has a lot of components and is very bulky.  The two aspects should not be confused.

Implementation Complexity (1 to 10)

1 means you can practically cut and paste the code and search and replace the class names in your code and it is implemented.

10 means that implementation of the pattern is highly dependent on the development of domain-specific algorithms in order to flesh out the pattern.  You may be able to cut and paste the code into your solution, but it will require additional extra-pattern algorithms which are domain specific.

 

Implementation Specificity (1 to 10)

1 means that the inner-workings of the pattern are the same all the time.  You can cut and paste generic pattern code (or use code snippets in the case of VS2005), replace the generic class names with the implementation-specific names and you are practically done.

10 means that the actual inner-workings of the pattern change dramatically depending on the implementation.  You will usually develop the pattern code from scratch.

This is a quotation of the intent as stated by the GoF – they said it best so why mess with it.

This shows a real life situation where the principle of the pattern is applied and the benefits realized in applying the pattern to the way the situation works.  The concept is borrowed from [Due 97].

In addition, it demonstrates how the actors in the real-life scenario represent the classes and objects in the design pattern and how they interact to fulfill the intent of the pattern.

This is an illustration of the pattern in Microsoft Windows, Office products or Visual Basic itself.  Please take note: this is not to say that the pattern is actually used.  It is just an example that shows how the pattern would operate (and an opportunity for the developers to use it in case it was not used).

Here is a scenario that could benefit from the implementation of the pattern.  This is, of course, implemented in VB.NET.  In almost all cases, the “Real Life Illustration” is different from the “Scenario – Sample Code."  Many readers will ask why.  Well first of all, the Real Life Illustration is easier to imagine since it relates to an everyday setting.  Also, the actors tend to have very separate roles and functions that clearly mirror the way the classes in the pattern behave.  Having come across it in real life it allows for an easier mental adoption of the pattern.  The code scenario is better suited, however, to implementation in code without being too unwieldy and hard to follow.  In other words, it is more code friendly.

The other point is that the double-scenario approach gives the reader a double dose of the pattern-thinking.  Added to this is the opportunity to explore the code-scenario and see how it follows from the real-life scenario.  In this way the reader gets the chance to double-check their understanding of the pattern.  Apart from the very mathematical-theoretical aspects of computer science, Design Patterns is one of the hardest topics and possibly the hardest topic that is required for every general software developer.  So be prepared to read many discussions and see many applications of design patterns before they really sink in.

UML – General

See below for a self-explanatory and quick crash course in GoF UML.  The UML diagrams used in this tutorial use notation which is similar to GoF notation with one major exception. In GoF UML, an aggregator class which holds a reference to several of the aggregatee class at once (usually through a datastructure such as a hashtable etc) would normally indicate the multiplicity with a filled-black-circle at the end of the association.  I have never been able to locate that black dot in Visio, so you will not see it in my diagrams.  However, in my diagrams, multiplicity is—usually—indicated by an asterisk “*” near the end of the association.

In the crash course below the notation being demonstrated is centered around the association between two classes.  So pay attention to the two classes that are connected, since the name of the class explains how it participates in the association with the class it is connected to.

Samples of UML associations

 

Most folks will already be familiar with the notation for Interface Implementation and Abstract Class inheritance and super-class inheritance.

A solid line pointing to a class usually indicates the Class holds a reference to the “Pointed-to” class. The GoF refer to this as an acquaintanceship relationship.

A solid line with an unfilled diamond at its base and terminating on the associated class with an arrow head indicates that the Aggregator class holds a reference to one or more instances of the aggregated class.  In the case of multiple aggregatees (usually contained in some sort of data structure such as a hashtable or arraylist), the GOF would normally indicate this with an arrow terminating on a filled dot.  However, I am unaware of black dots in Visio, so I have indicated multiplicity with an asterisk near the aggregatee class.

A Dashed line indicates that the class on the left (usually referred to as a factory class) is responsible for instantiating the class on the right, the product class.

 

Additionally, I must highlight the fact that in the GoF UML diagrams, the point on the Class diagram where the arrow originates is very important.  Do not just look at it as coming from the class, but from the actual member in the class.  So when you read the GoF book, remembering this will help you to get the most information from the diagram.

UML – Sample Code

This shows the structure diagram for the specific scenario that will be illustrated in the code sample.

Participants – Sample Code

Concept is similar to the GoF treatment of participants, but in this instance the equivalent of the GoF-Collaborations is incorporated into Participants section.

Sample Code (Highlights)

Code highlights are the critical structure and other aspects of the code that show the operation or structure of the pattern “in-lined” with the pattern discussion.  Code snippets are usually in Courier New Font.

Also included with each pattern is a downloadable zip file that contains a VB.NET solution.  In one or two cases there will be an included MS-Access database that is used with the solution.

Most of the sample applications are console applications and a few of them actually allow you to interact with them.  In most of the cases the classes are separated into namespaces and assemblies and you need to pay attention to how they are separated.  The assembly usually helps with accessibility issues, where only the classes in that namespace can directly refer to each other and they are hidden from other classes or clients.  In many cases the namespace also represents the Containable-Object-Group, the set of classes which would be reused together.

The namespaces I find useful when working with intellisense because it helps narrow down the classes you might want to work with.  In the picture below I am selecting from a set of classes that represent rhythms you can select when creating a song.  I am only interested in the rhythm classes, but without namespaces.  When I type the key-word New, intellisense brings up a little less than a million classes to select from.  But having factored the Rhyhm-classes into the Rhythm namespace, when I type “New Rhythms” it brings up a nice tight list as shown below.

Using Namespaces

Opportunities for and Costs of - Adaptation and Extension

These are ways in which the pattern allows for extension, usually by the addition of new classes or modification of existing classes so as to introduce new behaviors or new states.  It will normally include a short discussion on the actions which need to be taken to register the new classes in the existing structure so that they can be recognized by the system or developer and become usable.  You could liken this to the concept of a device driver that makes a peripheral accessible to a PC.

 

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.

Nails the pattern accurately in a concise easy to follow way.	Pretty good interpretation. Faults are minor or a matter of opinion.	Reasonable discussion or sample code.	Possibly too many clever tricks, skipped explanations etc, possibly inaccuracies in code.	Some flaws: Interface or scoping issues, bulky code, minimal explanation, etc.

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.

Useful Variations

Having criticized various authors on their rendition of the pattern, this is where I mention the useful, and to my mind acceptable, variations that I have seen in others’ work demonstrated in this work or otherwise dreamt up.  These variations are either improvements on the pattern or just a difference in an approach that you might not have thought of.  They may also involve the practical steps which have to be taken to implement the pattern in certain situations.

Pattern Tweaking

This is where I show how I would have done it differently by adding an interface or class to make the pattern even more robust.  I am sure the GoF had to deal with some tough issues, such as how to keep the pattern robust without adding too much structural bulk. This is where I add the structural bulk which I imagine they probably agonized over.

Advanced Discussion

If this is your first time reading about patterns, you would be justified in leaving this discussion until later when you really grasp what is going on with design patterns and that pattern in particular.  If you still want to read the advanced treatment, go ahead, but read it lightly; do not get stuck on things you do not understand or agree with.

Explanation of Pattern subscripts

Remember the subscripts applied to the pattern name?  In some cases, it may not be obvious why a pattern subscript (P+ P- E A R D M+ M- S+ S-) may have been applied.  In those cases, a bit of explanation as to which parts of the pattern the subscript applies to—and why—is given here.