Form Your Own Design Pattern Study Group

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 reach.

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 pattern.
• 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 week.
• 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 of 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 a 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 Method).
• 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 new to 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 it.
• 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 patterns.
• 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 example using?
• 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 do this?

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 GUI.

Related Reading Head First Design Patterns By Eric Freeman, Elisabeth Robson, Kathy Sierra, Bert Bates

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 group.
• 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 you know?
• 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 418.

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.

• Sample Chapter 3, The Decorator Pattern (PDF), is available free online.

• You can also look at the Table of Contents (PDF) and the full description of the book.

• For more information, or to order the book, click here.

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.