See this if you're having trouble printing code examples
Form Your Own Design Pattern Study Group
by Elisabeth Robson, Eric Freeman,
coauthors of Head First
Sure, you can pick up a book on design patterns, breeze through it, and think
you've learned something, but we all know patterns and object-oriented design
are deep topics. Like most complex subjects, patterns are best learned over
a period of time, not in a few sittings. Truly understanding patterns also
requires a lot of thought, insight into the true intent of each pattern, comparing
and contrasting a set of patterns, and considering the trade-offs in using
the pattern (not to mention understanding the basic OO principles behind
each pattern). Sometimes it also helps to have a helping hand to get you over
those little humps of understanding that are, for the moment, just beyond your
So we've got a suggestion for tackling patterns that's fun and social, and provides
a great environment in which to learn patterns: form your own study group.
What's involved? Just getting a group of interested individuals together and
dedicating yourself to reading and talking about patterns on a weekly basis.
Any group of interested individuals will do, but better yet, get your own engineering
team together to study patterns on a weekly basis (and get paid while you do
it!). Getting your own team together has another benefit as well, because patterns
become even more powerful when your entire team understands the shared vocabulary
created among the group members and the real underlying structure of the pattern.
Of course, study groups are nothing new; whether for studying classic literature,
discussing cinema, or learning about patterns, they have been around
for ages. In fact, Joshua Kerievsky has already put together an excellent guide to
forming a study group for the classic Design Patterns: Elements of Reusable
Object-Oriented Software, by Gamma, Helm, Johnson, and Vlissides (otherwise
known as the Gang of Four). If you're thinking about forming a group, you'll
find lots of good tips on his site.
The focus of this article, however, is to get people started forming study
groups using the Head First Design Patterns book. First, we should talk
about the difference between these two books. The Gang of Four (GoF) wrote the classic
design patterns book; it's the book that got the design patterns movement rolling, and no engineer's bookshelf is complete without it. The GoF book is part introduction to design patterns and part catalog of patterns.
Head First Design Patterns was written to be a learning guide to design
patterns. It closely mirrors the patterns in the GoF book, but is focused on
helping you understand the patterns and the fundamental ideas behind them rather
than providing you with a catalog of the patterns. (That's what the GoF book
is for!) We fully expect that once you've read and understood Head First
Design Patterns, you'll find other uses for it (a doorstop? firewood? bicep
curls?), and you'll move on to pattern catalogs. But to help you get up to speed
on the who, where, what, and why of patterns, lots of developers are starting
with Head First Design Patterns.
A Simple Recipe for Starting a Study Group
To start a study group, you need the following ingredients:
- a moderator
- a small group of interested individuals
- a meeting place and time
- a schedule of reading assignments
The moderator is responsible for finding and advertising a place and time to meet. As the moderator, you'll set the schedule of readings, run the meetings
(acting as a guide, not an authority), and keep the discussion moving. You
may also want to assign particular questions for participants to consider
before the meeting. Questions provide a great way to get things going
in a meeting and lead to further discussion. We'll suggest some questions and
an order for the readings in the next section.
Participants are responsible for completing the weekly readings before each meeting,
showing up on time, and participating actively in discussions. The participants may consist
of your own development group, a handful of interested individuals from your community, or a group of students in a college course spending time outside of
class to make sure they get it.
You can meet anywhere that is comfortable and allows easy discussion: your
conference room, a local high school classroom in the evening, or the local
Starbucks (although whiteboards are usually helpful in discussions).
A Sample Plan with Head First Design Patterns
Because Head First Design Patterns was written as a learning guide,
it's easiest to study it using the existing sequence of the chapters. In particular,
the OO principles used in the book tend to build on one another, so rearranging
the chapters could lead to some confusion.
We suggest tackling a chapter per week depending on the time you have available
for your meetings and for outside study. If you're short on time, some chapters
can be conveniently broken into two weeks, such as:
- Chapter 6: Command Pattern--study the basics, then in the second
week cover undo and macro extensions.
- Chapter 9: Iterator and Composite Patterns--spend a week on each
- Chapter 11: Proxy Pattern--in the first week, start with the proxy
pattern and RMI, and then cover the virtual and dynamic proxies in the second
- Chapter 12: Compound Patterns--study compound patterns in the first week, and then MVC in the second.
The rest of the chapters should be easily handled in one week each.
It's always good to have participants consider a few questions as they read, in order to help get discussion started in the meetings. We'll start you off, but we're
expecting you'll come up with even more interesting questions, and we encourage
you to post them in the Talkbacks section of this article so others can make
use of them. If the collection grows large enough, we'll organize them on the O'Reilly web site (giving full credit to the authors of the questions).
Here are a few to get you started:
Chapter 1: Strategy Pattern
- What are the main disadvantages to delegating behaviors like we do with
the Fly and Quack behaviors?
- Discuss the three design principles and how they support the Strategy Pattern.
- Do the Brain Power on page 27. Discuss examples of "shared vocabularies" that
might be meaningful to each of you.
Chapter 2: Observer Pattern
- Page 51 describes how the Observer Pattern is like a newspaper subscription.
Come up with several other real-world examples of the Observer Pattern.
- Lead a discussion on the Brain Power on page 57. Compare the implementations
CurrentConditionsDisplay on pages 59 and 68. In the first, we pass in
the measurements, and in the second, we pass in the
Observable, cast it to
WeatherData, and get the measurements using the public methods. Discuss
the advantages and disadvantages of each solution.
- Continue the fireside chat on pages 62 and 63 about push versus pull based
on your discussion of the Brain Power on page 57.
Chapter 3: Decorator Pattern
- Discuss the Open-Closed Principle on page 86 and how it relates to the
Decorator pattern. Make sure the group understands the principle and how
to apply it. If the group is knowledgeable enough, discuss how this principle
is used in other design patterns (for example, Observer, Factory Method, and Template
- Stage a debate about Decorator: one person should take the side of using
the Decorator pattern and argue the advantages, the other should take the
side of using inheritance and argue the advantages. See if the rest of the
group can come up with examples of when one solution is better than the other.
- Lead a discussion to make sure everyone in the group understands why the
Decorator interface must be separate from the component interface.
Chapter 4: Factory Patterns
- Bring a printout of a short program you've written.
- Go through your program and identify everywhere you use
create an object.
- Then go through your program and identify where it violates the Dependency
Inversion principle (pages 139-143).
- Then discuss if and where using a factory pattern might be appropriate
in your program and why. What classes in your program might change
in the future? Why?
- Discuss some techniques for handling errors in Simple Factory--what if
someone passes your Simple Factory a string that doesn't match one of the
types it supports?
- Imagine you are implementing a preferences dialog for an application. Discuss
why using a factory pattern might be a good idea and how you'd implement
- What are the key differences in the three factory patterns discussed in
Chapter 4 (Simple Factory, Factory Method, and Abstract Factory)? Make sure everyone
in the group understands the differences and when to use which of these factory
- Identify examples in which a factory pattern is used in a framework of
your language of choice (such as Java or C#). Which type of factory is your
- Discuss how Factory Method and Abstract Factory allow you to accommodate
change in your application more easily.
Chapter 5: Singleton Pattern
- Discuss how and why you would use the Singleton Pattern with the Factory
Pattern to create objects.
- What are some disadvantages to the Singleton Pattern?
- Discuss how you would implement a Singleton that limited the number of
instances to, say, five objects. How would you change the code on page 180 to
Chapter 6: Command Pattern
- Lead a group discussion on what it means to "encapsulate invocation" and
how this relates to the Command Pattern.
- Can you think of another real-world example of where you might want to
use the Command Pattern?
- Put on a skit where each person in the group plays a role in the Command
Pattern: the client, one or more commands, the invoker, and the receiver.
Act out the ordering of a burger in the diner (page 201). Act out the real-world example from the previous discussion.
- Discuss how you might use the Command pattern to implement a menu for a
Chapter 7: Adapter and Facade Patterns
- Discuss the Brain Power on page 244.
- Stage a fireside chat between Adapter and Proxy. Discuss the similarities
and differences in Adapter and Proxy. When would you use one vs. another?
Under what conditions would Adapter look like Proxy?
- Think of a complex system you have to use every day that you would like
a facade for. How would you simplify the interface in the facade?
- Discuss the Principle of Least Knowledge on page 265. Take a small chunk
of code you've written, and go through each line to see if it violates the
Principle of Least Knowledge. Are there any cases in which you think you should
change your code? If so, why?
Chapter 8: Template Method Pattern
- Take a design that has a lot of lower- and higher-level components (see
page 298). Now apply the Hollywood principle and clean up the design as a
- Lead a group discussion on the first Brain Power on page 305. Pick apart
the implementation of Sun's
sort(), which uses static methods instead of
inheritance. Did they do the right thing? Split into smaller groups if you
like, and then come back together to discuss or debate as a large group.
Chapter 9: Iterator and Composite Patterns
- Discuss the Brain Power on page 337.
- How does the Single Responsibility principle relate to the other patterns
- Make sure the group understands the differences and relationships between
components, composites, trees, and so on.
Chapter 10: State Pattern
- Continue the State versus Strategy discussion on page 411. Both patterns have
exactly the same class diagrams, but they differ in their intent. Try picking
a representative for each pattern, and have them debate who they are and how
they differ. Then open up the discussion to the entire group. Also see page
Chapter 11: Proxy Pattern
- Discuss the different types of proxy: remote proxy, virtual proxy, and protection
proxy. Make sure everyone in the group understands each type of proxy, and
come up with examples of each.
- Discuss the second Brain Power on page 435.
- Discuss the proxy zoo on page 488. Come up with at least one example habitat
for each type of proxy--in other words, examples of when and where you might
want to use that type of proxy.
Chapter 12: Compound Patterns
- Implement a new type of Duck Factory for the Duck Simulator, ducks that
eat. Add a new method to the Quackable,
eat(), and a new method to Goose,
chew(). How would you have to change the Adapter implementation to accommodate
Goose? What if the Quackologists wanted to be notified every time a duck ate
something--how would you change the Observer implementation to support this?
- Discuss the graph of the Model View Controller pattern on page 530. Stage
a skit representing a graphical user interface: one person is the view (a
button and a display); one person is the controller; and one person is the
model. When a user comes along and presses the button, what happens? How
does the display get updated based on the button press? Review which patterns
are involved and how they work in your skit.
- Now do the same skit for the web: one person is the client (user and web
browser); one person is the servlet; one person is the JSP/view, one person
is the bean; and one person is the model. Act out in detail what would happen
if a user were adding something to a shopping cart.
Chapter 13: Better Living with Patterns
- Discuss with the group some solutions that you may have used commonly.
Do any of these solutions fit an existing pattern that you've studied in
the group? If not, could your solution qualify as a potential pattern (page
579)? Why or why not?
- Find a catalog description of a pattern not covered in the main part of
the book (one of the patterns in the index). You can use the GoF's design
patterns book, or find one on the Web. Review the pattern with the group and see if you can understand it; then come up with at least one example of
when and how to apply this pattern that is not described in the catalog or the Head First Design Patterns index.
Now It's Your Turn
Well, that should be enough to get your started; all it takes is a few people
with the interest, our book, some time, and a meeting place. We look forward
to hearing how your studies go!
In October 2004, O'Reilly Media, Inc., released Head
First Design Patterns.
Elisabeth Robson is an author and software developer. She is coauthor of O'Reilly's Head First Design Patterns and Head First HTML with CSS & XHTML.
Eric Freeman is a computer scientist with a passion for media and software architectures and coauthor of Head First Design Patterns. He just wrapped up four years at a dream job--directing internet broadband and wireless efforts at Disney--and is now back to writing, creating cool software, and hacking Java and Macs.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.