Head First Design Patterns

1You don't reuse code, you reuse experience

That's the book's promise, stated in chapter 1: "instead of code reuse, with patterns you get experience reuse" (ch. 1). A pattern is not a library you install: it's "a solution to a problem in a context" (ch. 13), a trap thousands of teams hit before you, and the way out they eventually found. And the real value is not where you think: "don't underestimate the power of a shared vocabulary" (ch. 13). Saying "put an Observer on that" in a meeting replaces ten minutes of explanation. A pattern is first and foremost a word.

2Encapsulate what varies (the flying rubber ducks story)

Chapter 1 tells the story of Joe, developer on the SimUDuck game. His bosses want the ducks to fly. Joe adds fly() to the Duck superclass… and the rubber ducks start flying too: "a localized update to the code caused a nonlocal side effect (flying rubber ducks!)" (ch. 1). The book's founding lesson: "identify the aspects of your application that vary and separate them from what stays the same" (ch. 1). Flying, quacking: it varies per duck, so you pull it out of the class and plug it in as a swappable component. The book claims this principle "forms the basis for almost every design pattern" (ch. 1).

3Favor composition over inheritance (the Starbuzz nightmare)

Starbuzz Coffee has one class per beverage. Add condiments (milk, soy, mocha, whip) and you get one subclass per combination: MochaSoyWhip, DoubleMochaMilk… explosion. The Decorator solution: a base drink you wrap in layers of condiments, Russian-doll style, each adding its price and description while delegating to the next. And the book defuses the classic confusion: yes, the decorator inherits from Beverage, "but we're using inheritance to achieve the type matching, not to get behavior; the behavior comes through composition" (ch. 3). Inheritance is frozen at compile time; composition can be rewired at runtime.

4When you see new, think "concrete"

The Objectville pizzeria: an orderPizza() full of if (type == "cheese") new CheesePizza(). Every new pizza, every franchise (New York, Chicago) means reopening that code. The book's mnemonic: "when you see 'new,' think 'concrete'" (ch. 4), meaning hard-wired to one specific class. The Factory patterns move creation to a dedicated place, and the principle behind them: "depend upon abstractions, do not depend upon concrete classes" (ch. 4). With rare honesty: right after stating its three strict guidelines, the book admits that "clearly, every single Java program ever written violates these guidelines" (ch. 4). They're compasses, not laws.

// ✗ Before: creation is tangled with the recipe
Pizza orderPizza(String type) {
    if (type == "cheese")     pizza = new CheesePizza();   // ← changes with every
    else if (type == "clam") pizza = new ClamPizza();     //   new pizza
    pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box();  // ← never changes
}

// ✓ After: the varying part is delegated to the factory
Pizza orderPizza(String type) {
    pizza = factory.createPizza(type);  // the only place that knows the classes
    pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box();
}

The recipe (prepare, bake, cut, box) never moves again. Adding the pizza of the month reopens exactly one file: the factory.

5The waitress doesn't know what's on the order slip (Command and decoupling)

How can a home-automation remote drive a lamp, a hot tub and a stereo without knowing their details? The book answers with a diner: the customer writes the order, the waitress carries it without reading it, the cook executes it. The order slip is the Command pattern: a request wrapped in an object you can store, queue, or undo. The same spirit gives chapter 8's Hollywood Principle: "don't call us, we'll call you" (ch. 8), the high-level component decides when to call the details, never the other way around. That's the skeleton of every framework you use.

6MVC is not a block, it's three patterns assembled

First, what MVC means when you're coding: three boxes with separate roles. The Model is the data and its rules (a shop's cart and its total). The View is what's displayed (the cart page). The Controller is what receives your actions (the click on "Add"). The full loop: you click "Add to cart", the controller receives the click and asks the model to add the item, the model changes, recomputes the total and announces it, the view redraws with the updated cart.

What chapter 12 reveals: "MVC is a compound pattern consisting of the Observer, Strategy and Composite patterns" (ch. 12). In other words, every link in that loop is a pattern the book has already taught.

• The Model → View link is Observer (the subscription). The cart doesn't know the page displaying it. It keeps a list of subscribers and shouts "I changed". That's why you can add a second display (the little item counter in the top corner) without touching a line of the cart: the counter subscribes, that's all.
• The View → Controller link is Strategy (the plugged-in behavior). The page doesn't know what to do with a click: it hands it to its controller, a plugged-in part you can swap (the ducks from idea 2). Same page, swappable behavior: in demo mode, you plug in a controller that records nothing.
• The View's structure is Composite (the tree). The page contains panels that contain buttons. Telling the page "redraw yourself" redraws the whole tree, without asking who's a group and who's a leaf.

A note for web devs, because this notification loop can feel off: it's the original MVC, the desktop-GUI one, and it lives on today in reactive frontends (Vue, React), where components subscribe to state. Server-side (Symfony, Laravel), HTTP flattens the loop: on each request, the controller queries the model and hands the result to the view itself, then everything vanishes. The Observer link never gets time to exist. The book covers this web variant under the name "Model 2" (ch. 12): same roles, but the postman only rings once.

The reward of the split is the same in both variants: each part can be replaced without touching the other two. And once you've seen that, frameworks stop being magic: they're assemblies of parts you know.

7Singleton, the pattern that ships with its own warning label

The Singleton guarantees a single instance (the book's chocolate boiler: two instances = 500 gallons on the floor). It's the simplest pattern in the catalog, and the book spends half the chapter on its traps: two threads can create two instances at once, the fix (synchronized) "can decrease performance by a factor of 100" (ch. 5), and it concludes: "Singletons are meant to be used sparingly; if you are using a large number of them, take a hard look at your design" (ch. 5). A patterns book that teaches you to distrust a pattern: exactly the right mindset.

8The best chapter explains when NOT to use a pattern

Chapter 13 is an antidote to the book itself. The golden rule: "always use the simplest solution that meets your needs, even if it doesn't include a pattern" (ch. 13). The warning, spelled out: "overuse of design patterns can lead to code that is downright overengineered" (ch. 13). And the progression from the beginner who wants "a pattern for Hello World", to the intermediate who forces them everywhere, to the zen mind that sees them naturally and reaches for simplicity first. Even the self-criticism is there: about their own six-pattern duck simulator, the authors admit that "some of these patterns were big time overkill" (ch. 12).