GoF Design Patterns: Rapid Learning Tips
"I only wish I saw this link before I read the book."
-- *nix Documentation Project Forums
Design Patterns Catalog is optimised for reference usage, not for
learning. Instead of reading cover-to-cover, there are certain properties
you can exploit for to learn design patterns more rapidly. The tips here
show you how to do just that.
Tip: Learn Patterns In The Following Order
The GoF text doesn't order patterns in a manner
suited for easy learning, e.g. from easiest to hardest.
Here's the most important tip. The original text groups patterns in
three categories, and then alphabetically within each. All good for
reference purposes, but lousy for learning. For example, the first pattern
is Abstract Factory, one of the more
sophisticated entries. A much simpler starting point, Facade, is buried in the middle. The alphabetical
order is unnecessary, and even the categories are not especially
meaningful, for learning purposes.
So it's clear you need to learn the patterns in a different order. The
problem is you don't know them yet, so how can a pattern newcomer decide
on an order? The answer is to use an existing "learner's roadmap" - that's
why I'm listing a suitable order below. Hopefully, any future revision of
the book will do likewise.
The order I recommend is based on three principles:
With that in mind, here is the order I recommend. As in the book, page
numbers are shown in parentheses.
- Group similar patterns, as the commonalities will reduce the overall
effort. You're effectively learning 16 or so patterns with some
variations, rather than 23 individual patterns.
- Early on, focus on the simpler patterns.
- Early on, focus on the patterns you have probably
... Easy GoF Patterns. These easy
patterns concern only one class, or a straightforward relationship among
several classes. Incidentally, don't discount them as being ingenious;
their ease of learning actually stands testimony to their cleverness. Learn
in the following order ...
- Facade (185) All the ingredients for
a starting pattern. Conceptually clear, solves a problem many
developers have experienced, many real-world metaphors. Good
introduction to the world of patterns.
- Singleton (127) Also very easy to
- Mediator (273) A "Man in the
Middle". Again, typical problem with a straightforward solution.
- Iterator (257) Conceptually simple
problem and solution, Should be a breeze for anyone who has looped
across a collection using the standard Java 1.0-1.4 iteration
- Strategy (315) The first pattern
here to be centered around polymorphism, making it a bit more
sophisticated. But it's still quite simple as it concerns a single
- Command (233) SIMILARITY:
Command is almost identical to Strategy. That is, you call an "execute" method
and the instance executes itself. The only difference here is Command "feels"
more dynamic - it is, at some level, triggered by an external agent
(e.g. an end-user). In contrast, a Strategy often represents a business rule, e.g.
tax calculation. So the application may vary, but what actually happens
- Builder (97) SIMILARITY: This is
really just a special case of Strategy,
applied specifically to the problem of creating an object. The name is
misleading, because the most important logic is actually in the Director. The Director has a fixed high-level
procedure, but the actual construction depends on what its building,
and that construction process is encapsulated in a Strategy object called the Builder.
- State (305) SIMILARITY: This pattern
is quite similar to Strategy and Command - keep these patterns in mind. It is
based on polymorphism, and once again is centered around a single
superclass/interface with any number of subclasses. Unlike those
patterns, it is not intended to perform a single action. Instead, is
says how any number of actions are performed while in a certain state.
Don't complicate things by worrying about state transitions; that's
actually not the main point of State. Once
you understand that State is about what
happens in state X, the concept of state transitions follows
- Template Method (325) Another
pattern involving polymorphism. Still only a single class hierarchy.
Also important to see how this is an alternative to
- Factory Method (107) SIMILARITY:
This pattern is just a specal case of Template
Method. As stated in the text, it applies only to Template Methods which involve the creation of
an object. Note that most people nowadays use a
different definition: a public creation method, typically of the class
(or subclass) that the method belongs to.
- Memento (283) With its involvement
in Undo functionality, this pattern is
related to Command. It's easy to
understand once you see that certain commands cause loss of
information. That is, you can't reverse the effect of a command just by
knowing the final state. For instance, the command "multiply by zero"
will always lead to zero, so how can you reverse it to get the original
number? The answer is to attach the original number to the command. The attached number is a memento
- Prototype (117) Actually very
simple, but is listed last here because it is not used very much in
practice. Actually, the structure diagram shows a class hierarchy, but
the pattern is essentially about a single class being cloned.
... Intermediate GoF Patterns. Now
that you've been exposed to the basic patterns, you are well equipped to
read up on pattern theory in general. Then, when you're ready to proceed
- Proxy (207) Should be familiar to
anyone who has used a web proxy.
- Decorator (175) SIMILARITY:
Proxy is a special case of Decorator. It's worth learning Proxy first, because it's a more familiar
situation. Once understood, it's not so hard to see how a Decorator could wrap classes to perform tasks
other than those performed by Proxy. Proxy is usually used with regard to security and
networking, and typically a class with a proxy cannot be accessed
directly. In contrast, a Decorator is
usually used to enhance an existing class's functionality. A client can
freely choose whether to wrap a class with its Decorator(s). As with the Strategy-Command relationship, Decorator shares the same mechanism as Proxy, varying only in the application area and
style of use.
- Adapter (139) Learn along with
- Bridge (151) SIMILARITY: Similar to
Adaptor, but with subtle differences, to Adapter. Good to learn these in
tandem and most importantly, to understand the emphasis here is on
up-front design, whereas Adapter is usually used to avoid changing
existing classes. So a Bridge is usually designed when neither end is in place. But both ends (sometimes just one end) of an Adapter already exist
before the Adapter is written to glue them together. Many Java
frameworks are an example of Bridge, where a set of interfaces are
listed and indivudual vendors can then provide their own
- Observer (293) Makes some
sophisticated use of object-oriented constructs, but not especially
difficult as there are some great real-world metapors, viz., publishing
and broadcasting. Also, should be intimately familiar for anyone who has
written GUI applications or subscription protocols like RSS.
... Advanced GoF Patterns. Don't worry
- they're all very accessible. A design pattern is supposed to be a
distinct, simple, idea, and the GoF patterns have certainly adhered to
this principle ...
- Composite (163) A recursive, tree-like
data structure, formulated in OO terms.
- Interpreter (243) SIMILARITY:
Interpreter may seem a bit unfamiliar as
you've probably not written a parser before, but it's actually just a
special case of Composite applied to
parsing. Note that this pattern is the odd one out in the overall GoF
collection, because it is domain-specific - its applicability is limited
- Chain Of Responsibility (223) Best
learned with regard to a Composite
structure. Confronted with a request, children try to handle it, and if
they can't, they pass it to their parents, and so on, until eventually
some class along the chain can deal with it.
- Abstract Factory (87) Often
misinterpreted as being just a Factory, but actually it's more than that
because it allows for creation of class families.
- Flyweight (195) Think of a pool of
expensive objects which are shared, such as EJBs or database connections.
This pattern may not be familiar to everyone, hence this pattern is
considered a bit more difficult.
- Visitor (331) Alphabetical order lined
up with complexity in this case, because this pattern does deserve it's
place at the end of the GoF text! It helps to see Visitor as an after-the-fact substitute for
Tip: It's the Patterns, Stupid!
The pattern format is simple enough to require no introduction. Read the
introductory material, and any other info on pattern theory, only when you
are confident with some of the patterns themselves.
Tip: Only Read High-Level Pattern Details
The great thing about patterns is their consistent, well-organised, format.
Use this format to concentrate on high-level information and filter out the
detail such as code segments. On first reading, you
only need to familiarise yourself with the "Intent", then glance at the
"Structure" diagram, and finally read just the "Motivation". Only
read other sections if you don't understand anything here.
Tip: Think of Real-World Metaphors
I'm not talking about how you've used the patterns in existing software.
I'm talking about patterns of social structures, building architecture, and
so on, which are similar to the design patterns. For example, the Facade pattern is illustrated by an office
receptionist, and the Proxy pattern is
illustrated by a CEO's personal assistant.
Update: I have
created metaphor examples for all
GoF patterns here.
Tip: Therefore, BOOM!
Here is a tip for authors of patterns which will also help you in learning
them. A pattern should read as "Therefore,
BOOM!". A clear problem that frustrates you, makes you think "how can I
ever deal with this", and then BOOM! You slap yourself in the realisation
that such a simple solution exists. The GoF patterns are cunning in their
simplicity - if you understand the pattern, you should be able to state the
problem in one sentence and the solution in another.
Patterns are now required learning for most developers. GoF (Gang of
Four/Gamma et al.) Patterns are now part of software folklore, used daily
in real-world development and mandatory education for students and
practioners seeking certification, as in the Sun
Certified Enterprise Architect (SCEA) exam. The tips on this page help
you get a heads-up as quick as possible. They are based on my experiences
in using the patterns, mentoring other developers, and lecturing at
The most important thing to understand is the original text is written
primarily to support the task of real-world development, rather than a text
for pattern newcomers. It is a reference text, and you need to approach it
differently if you are learning the patterns. For instance, the patterns
within each section are ordered alphabetical - clearly, that's not the
fastest order to learn them in.
By following these tips, you can reduce a 400 page book down to about 50
pages of the most useful information, and cover these pages in a more
natural order. So learning GoF patterns won't seem quite as much work. Once
that's done, you can go back and pick up some of the detail.
This work is licensed under a Creative Commons Attribution 3.0 Unported License.