Head First Design Patterns: A Brain-Friendly Guide

Head First Design Patterns is an excellent introductory text for design patterns, plus object oriented design in general. Each chapter in the main part of the book covers one or two of the most common design patterns in great depth, including motivation, sample code, exercises, as well as answering many of the questions a reader is likely to have. Additionally, one of the things that makes the book great is that each chapter uses the context of the design pattern to introduce one or two important object oriented design principles such as the Open-Closed Principle and the Principle of Least Knowledge. Less common patterns are covered in the appendix, although in much less depth. I bought this book for my 17-year-old nephew -- who is in the second year of a high school computer programming course -- as a companion to the Gang of Four book. I think the two books work well together, with Head First Design Patterns working as a more accessible introduction to design patterns, and the Gang of Four book serving as a reference for later on. He definitely finds the Head First book easier to read as a beginner. Even I, with a college degree in Computer Science and 20 years in the software development industry, find it valuable, at least as a review. For those wondering about which edition they will get, I bought this book through Amazon and received the tenth anniversary edition, updated for Java 8. The main difference is that it takes advantage of the newly-introduced Lambda Expressions. Although the book uses Java throughout, C# developers will have little if any trouble with the examples. In many cases, the code is identical. Slight nitpick: Some of the patterns in the appendix are given short shrift in the interest of space. For example, the section on the Visitor Pattern leaves out the important fact that one of the main motivations for the pattern is to overcome the limitations of languages that support only single dispatch. Said another way, the Visitor Pattern is trivial to implement in languages that support multiple dispatch. For more detail on these design patterns, I recommend the Gang of Four book, or online resources.

I purchased this book about a year ago and devoted a number of hours each week going through it. I am a software developer by trade, but never took a computer science course in my life, mostly because I was self-taught as a kid and all of this pre-dated the Web by about 20 years. In any event, one area where I knew I was lacking was a formal understanding of design patterns. I was in the middle of a fairly large enterprise application, and while I was fully versed in Object Oriented Programming (and had even taught it in the past), I realized that everyone we were hiring out of college "spoke" a different language than I did, talking about singletons, factories, MVC, etc. This book covers those and many, many more, in a completely involving and revolutionary way. It's basically designed with the Java language in mind, but I'm a .Net developer, never having learned Java. However, the book is so thorough and intuitive, that I decided to do all of the examples in C# (close enough to Java that in many cases, there's almost a 1-to-1 relationship between my home-grown example and the one in the book. So for me, the book's benefit was two-fold: exposure to both design patterns and the Java language. In many cases, I was able to ".Net-ify" the examples to take advantage of specific features of .Net. A good example was in the Observer pattern where you have an object that changes over time, and other objects ("observers") need to be aware of this change. The book presents a language-agnostic approach, where the observable object registers all of its observers, and cycles through them notifying each one that it has changed. With .Net, it's much easier (and more appropriate) to implement this using events, where the observable object doesn't care who's watching, it just announces "I've changed!" and each observer can then decide how to handle that event. But I digress... ultimately, I just threw myself into this book, doing every example as written, and then modifying those examples to function with the .Net mentality. I even did all the pencil exercises, puzzles, etc. It's all part of the learning process, right? So, in a nutshell, if you need to learn design patterns, get this book. It's a lot of fun, and chock full of great information and examples that you'll be able to apply to your own projects right away.

This book aims to teach us how to reuse design patterns that have been used over and over again. While this book does not cover all patterns in detail, it covers the patterns that are commonly used according to the authors' mind. In overall, this is the book you want to buy as a starting point to learn design patterns. To begin with, before reading this book, you have to know about Java programming language along with the object-oriented features such as encapsulation, inheritance, and polymorphism. Bear in mind that by having solid object-oriented knowledge does not make you a good object-oriented designer. I thought the opposite until I read this book. For those who do not know the language and/or the object oriented feature, they should study them first before attempting to read this book. When reading this book, please note that the primary intention of this book is to teach you about design patterns. Therefore, if you find the examples are not what you expected (too simple, childish, imaginary, and so on), you need to know that the examples are made as simple as possible so you can concentrate on learning design patterns. Unfortunately, some people just do not understand this approach. They probably want examples that have hundreds line of code to explain each patterns and I am very sure if this was the case, they would give bad review anyway by arguing that the examples are too complex. The only negative thing is the fact that not all 23 patterns are covered. I wish all of them were covered in a single book and even if the price were twice as much I would certainly buy it. I do not know why the authors did so. They covered only around 13 and cramp the others in 20 pages in the appendix. In my personal experience, after reading this book, it changed my paradigm toward object-oriented design and made me ask myself, "Why I didn't buy this book earlier?" Had I bought it earlier, my campus projects would have gone easier. In addition, ever since I read this book, I often think about the pattern(s) that can be applied in the other programming books' code example, especially when the examples have too many if and if else statements as they could be refactored using state pattern or command pattern. The reason some programming books do not bother with design patterns (even though the authors probably know about it) is because not their focus in their books. That is why this book is useful. Also, please be aware that in this book source code, the instance variables are not declared private. In reality you have to make it private according to the principle of the least privilege. Finally, I highly recommend this book to anyone who already knows Java and its object-oriented features as it helps you to learn commonly used patterns and to design better using best design principles (open closed principle, encapsulate what varies, etc).

I am a professional IT trainer and have read dozens of technical books on software, languages and best practices over the years and, for me, I tend to prefer the ones that cut to the chase and don't waste pages on irrelevant or tangential information. Also, when most authors try to inject humor into a technical book, it reminds us why these people don't get paid to tell jokes for a living. The Head First series takes a different approach to presenting its content. It's almost written like a junior high school text, with crossword puzzles and other brain teasers to help solidify the content just presented. But, the reviews on this book were very good, so I decided to give it a shot and after I put my "just the facts" desires aside, I found that the book doesn't disappoint. Design patterns are generally hard for people to assimilate. Many patterns share common traits and it can be confusing to try to understand when a particular pattern would be beneficial. This book does a great job at teaching patterns, but what it really does well is teach Design Principles in tandem with the patterns. This is the way to learn this stuff. Learn the principles and why they are beneficial and then it becomes easy to learn why a particular pattern is used as a way to implement the principles. Yes, there is humor (some actually humorous) and the presentation is intentionally sophomoric, but I found that presented this way, it keeps your interest in what is normally the most boring of all IT topics. Well done!

I was kind of uneasy buying this book, I have NEVER bought a head first book...I've seen them at some of the larger book retailers and I've thumbed through them and quickly dismissed them as a gimmick and "for kids" due to all the illustrations and goofy quotes...I feel very sorry about that now, I have a TRUE FEELING that I would have a much deeper understanding of C++, Java, and PHP if all of Head First's books are written as well as this one...this book DOES make lots of use of "out of the ordinary" techniques when it comes to a software development book. It DOES NOT give detailed "cook book" code samples, and it DOES NOT promise to teach you EVERYTHING there is to know about Design Patterns. I wouldn't even say it gives you MANY "REAL WORlD" examples, nothing that you code in this book is OVERLY COMPLEX. What this book DOES DO, is offer a SIMPLE, VERY EASY TO UNDERSTAND, VERY INFORMATIVE, AND ENTERTAINING way to LEARN the most useful design patterns. This book is everything I wanted and more, it is not a Book's job to teach me how to be creative, or how to implement their exact code into my client's software...it does do EXACTLY what it should and presents the information in an EASY to grasp way without wasting your time. I would BUY THIS BOOK NOW. WARNING: If you don't have a strong OO background before getting this book you may be making a mistake, the authors do an OK job trying to explain OO principles but if you don't understand some of the more common terms (or haven't looked at them in quite a while) it really helps to brush up prior to reading this book. I HIGHLY recrommend Object-Oriented Thought Process by Matt Weisfeld as an introduction or refresher, it is a FANTASTIC read on OO.

Simply put, this book is amazing. Now, I've gone through my fair share of tech books on various subjects and not once has a book grabbed my attention quite like this one has. This book is a very fun and easy read, yet I have never absorbed so much information from any other tech book like I did with this one. It takes learning back to the old-school. It's almost like getting in touch with your inner-child. I was reminded of how learning was back in elementary school. It sounds bad, but really it's the best way to grasp such a complex subject. The pages are riddled with elementary school-esque drawings and humor is peppered throughout this book so heavily that you can't help but turn to the next page and keep on reading. Now, don't you think that this book is a complete breeze. Yes, it is an easy read, but you will still have to study this book to really absorb the information. There are some practice exercises that can seem a bit daunting at times, but once you do figure it out you will get the "I am THE man! (or woman)" feeling. You will get a rush of understanding that only the best books can provide. The design of this book truly is genius. I wish there were more books like this out there. I have never learned so much - so easily. I give this book my highest recommendation EVER! yes... EVER!

I bought this book because I got into the wave of designing software using UML designing tools. As a beginner I found it useful but now looking back this won't save you from countless hours of breaking your head how to joggle with the design to fit in the requirements. And the childish design it actually helps. The books looks fluffy and this lets you see the skeleton of ideas from behind. When talking about requirements I speak about memory footprint, speed of execution, flexibility, extensibility and so on. I think this book will help you understand why the solution that you found by yourself actually work and improve the ones that you already have. If you think that you'll become a good designer reading this, you are in for a big surprise. As with most of things good guidance and a lot of work helps materialize a good theory. Take the book and make a few designs. In the first designs don't think about any requirements just design to become able to spot the most obvious design mistakes. Than go back and impose harder design requirements like how you can tweak it to become faster or consume less memory while still analyzing the design from the book perspective. After a few designs you'll definitely become a better designer. Another book that helped me was Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition) (Addison-Wesley Professional Computing Series) . This one is very practical and will help you understand that design patterns are dust in the eyes some times when memory and speed requirements are very tight. This is my advice from my own experience. If it helps than I guess it is a good advice.

Plenty of people have commented about the teaching style, and I do not have much to add in that regard. I bought this book as an adjunct to the GoF book, and it serves nicely for me. To put this in context, my favorite chapter in GoF is the second chapter, where they provide the design for an hypothetical editor. Learning and remembering is easier for me when it is tied to something concrete. Like many others, I could do with about 1/2 as much material, but it is easy enough to start skimming when they repeat themselves. Where I feel this book seriously goes astray is in the problems they choose to use. For reasons I don't understand, they choose to illustrate several design patterns for a problem domain they should not be applied to. For example, they illustrate the decorator pattern by designing a solution for calculating the prices for a coffee shop. They start out well, showing a naive explosion of classes (HouseBlendWithWhipAndSoy, DecafWithSteamedMilk, and so on), which is clearly a bad approach. Yet, they still implement a number of classes - 4 different classes for each beverage type, and then a decorator for every additive you might want (mocha, soy, milk, whip, etc). This is clearly silly; can you imagine telling a company that every time they want to add a new drink or drink additive you have to modify code? In the very next chapter we are introduced to the Factory pattern. Before long we are once again writing specialized classes to deal with composition: You have the Pizza class, then the ClamPizza class, a CheezePizza class, a VeggiePizza, and so on. You deal with that with composition (covered in the very first chapter!), not types. What is particularly distressing about this example is that they rightly showed what a maintenance nightmare it would be to have to write a NYStyleCheesePizza, ChicagoStyleCheezePizza, and so on. Again, imagine telling a restaurant owner that every time he wants to introduce a new pizza on the menu that you need to write code and deliver a new application to him. Madness. I anticipate a retort that these are toy problems meant to illustrate the idea. But we use decorator patterns all of the time in the real world, on real problems. Why not use one of those problems in the book? Again, I recall chapter 2 of GoF; their example problem (a text editor) is very real world, very understandable, and yet is no more complicated than the toy problems in this book. This form of OO, where inheritance and types are used as the main tool in the toolbox is what we see out of junior programmers every day, and it just makes for unmaintainable code. I do like the exposition style, but loathe (some of) the examples. I guess that averages out to 3 stars? I dunno. I would not hand this book to a junior programmer for fear of them being led astray. I would hand it to an intermediate programmer whose skills I know with strong caveats about the quality of the examples. class VeggiePizza. Really!