Book Review

Head First Design Patterns

Abstract

No innovation after structured programming and object orientation has had as much impact on the art of constructing software systems as design patterns. In fact, it is hard to understand and practice effective object orientation without being conscious of design patterns and their suitability for the problem at hand. The same is true for teaching and learning basics and principles of object orientation. It is often much easier to first learn about the design problem and the pattern based solution and then figure out how the solution satisfies principles of object orientation. This is the exact approach taken by O'Reilly's Head First Design Patterns book.

There are a number of other things quite remarkable about this book. Following the Head First pattern (pun intended) of authoring books pioneered by co-authors Kathy Sierra and Bert Bates, it introduces the concepts by talking about real life scenarios, such as serving hungry stomachs in a restaurant, and landing a job with help of a head hunter. A host of other non-traditional means are used as well: exploring problems, solutions and trade-offs through short conversations, non-linear presentation of content with hand-written in-place annotations, ample supply of humorous pictures and repeated re-enforcements through quizzes, puzzles, cross-words, bullet points and other such means.

As we all know, use of appropriate metaphors could be very effective while learning new concepts. After all, most of us have learnt the value of static type checking in programs through the metaphor of electric plug and socket. It is so easy to visualize the damage to a 9V device when plugged into a 110V electric outlet. Taking the same idea a step further, the book introduces the Adapter Pattern by talking about the power adapter required for plugging-in a 2-pin US laptop power cord to a 3-pin European wall outlet.

The unique and non-traditional presentation style is certainly an important aspect of the book, and one could write a review analyzing just this. But that would miss the point. The book and its style stand out by using this style to make a somewhat abstruse topic much more accessible to a much wider audience.

No review of a patterns book can be complete without a mention of the venerable Design Patterns - Elements of Reusable Object Oriented Software by Erich Gamma et. al., also known as the GoF Patterns, and how the book under review relates to it. When the GoF Patterns book first came out almost ten years ago, it revolutionized the developer community by its thoroughness, attention to details, and uniformly structured presentation of patterns. Head First Design Patterns differentiates itself by taking a different, more accessible approach to introduce and explain patterns. This is best said by actually comparing the presentation of Observer pattern, a widely used design pattern in a number of systems, in these two books.

The GoF description of the Observer pattern begins with a terse statement of intent, listing of synonyms, and a brief discussion on motivation for the pattern. Then it talks about the benefits and liabilities of the pattern under Consequences section. This is followed by a long list of implementation issues and sample C++ code. The discussion concludes with a note on known uses of the Observer pattern in publicly available systems and a brief mention of related patterns. By the way, this is the GoF structure for all patterns.

In contrast, Head First Design Patterns description of the Observer pattern begins with statement of work from a fictional company for design and development of a system and a straightforward implementation of the system. This is followed by a discussion on limitations of this implementation, building the motivation for using a better solution. At this point, the presentation takes a detour and explains the Observer pattern by drawing analogy to delivery of newspapers to subscribing readers by the publisher. There is another real life analogy where programmers find jobs with help of a recruiter. Only now, when the reader has a high level understanding, the formal description of the pattern is presented and how it promotes loose-coupling, an important Object-Oriented Design principle. Then comes an improved version of the earlier implementation that makes use of the Observer pattern and resolves earlier limitations. Another thing that Java folks would appreciate is a discussion around Java support for the Observer pattern with class java.util.Observable and interface java.util.Observable, and its limitations.

One aspect of patterns that deserves special mention, and finds fair coverage in the book, is that their use in a particular situation involves trade-offs or a careful analysis of benefits and limitations. In fact, the book itself makes certain trade-offs: rather than trying to cover all patterns catalogued by GoF or later authors, the book focuses on comprehensive coverage of few most often used patterns. The ones that make the cut are: Observer, Decorator, Factory, Singleton, Command, Adapter, Facade, Template, Iterator, Composite, State and Proxy. Few others find brief mention in an Appendix suitable titled Leftover Patterns: Bridge, Builder, Chain of Responsibility, Flyweight, Interpreter, Mediator, Memento, Prototype and Visitor. Besides these, the first chapter talks about the Strategy pattern while introducing the idea of patterns and the chapter on compound patterns explains Model-View-Controller framework as a solution that involves multiple patterns, pointing out an important aspect of patterns -- they tend to occur in groups.

Another area of trade-off is the use of a single programming language -- Java, and only Java, is used for all sample code, implementation issues and benefit-limitations analysis. This is actually a good thing, for it allows the some of the discussion to be much more concrete and have more direct relevance to a big developer community.

So, what is not so good about the book? Actually not much, though I do want to talk about something that I made a note of. When I was learning object orientation after working on few C projects, the benefits of inheritance became apparent only after reading an article that explained how treating squares, rectangles, triangles and circles as shape objects allowed the same code to draw, resize, move and group all of them and included the complete listing of all the code that I could compile and run on a PC AT. Now that was effective, much more than pages of description about how cars and trucks are both vehicles and hence they inherit attributes like weight, horse-power, no. of wheels etc. from vehicle. What I am coming to is that use of real-life scenarios helps in understanding programming abstraction to some extent but do not provide the deep insight that one gets by actually seeing these abstractions where they really belong, in software itself. Though explaining the inner workings of real software is hard in a book due to space considerations, some of the benefits could have been realized by simply referencing and talking about Java library classes and other major open source software where these patterns have been used extensively. The interested reader could then go and dig further by himself or herself.

My take on the book? Go for it if you had been hiding in some island and have never heard of design patterns or more likely, have heard about design patterns but are not able to spot them in existing implementations or don't quite feel comfortable about employing them in your own implementations. Eventually, you should get the GoF Patterns book for reference but this one is a good way to get started. I would also recommend this if you are an instructor and are looking for creative ways to introduce OO and design patterns concepts.

© 2005 by Pankaj Kumar. All Rights Reserved. You may use the content of this article, including the source code, in your programs and documentation. In general, you do not need to contact me for permission unless you are reproducing a significant portion of the article or code for commercial purposes. For example, writing a program that uses the code for personal or company use does not require permission. Republishing this article, even with proper attribution, does require permission. Similarly, incorporating the code in a program that you sell for profit requires permission.

You are welcome to send me comments, suggestions or bug fixes. I will look into those as and when time permits and may even publish the good ones on this page.

You can contact me by sending e-mail to pankaj.kumar@gmail.com.