Errata

Head First Design Patterns

Errata for Head First Design Patterns

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
PDF Page p. 156 and 157 of Design Patterns - Second Edition
"UML" schema

In my opinion, Client is not "composed" with the interfaces AbstractProductA and AbstractProductB?
Same remark, next page, NYPizzaStore is not "composed" with the interfaces Dough, Sauce, Cheese and Clams.
See also the code of PizzaStore and NYPizzaStore in the package headfirst.designpatterns.factory.pizzaaf.

 Claude Lepère  Apr 16, 2024 
Printed Page 2nd ed, page 198 and all similar throughout book
All annotations, done in what is supposed to look handwritten notes.

(2nd edition, December 2020)

In all annotations on diagrams, code, sample output, illustrations and similar that are supposed to look like handwritten notes:

The light gray on white font >works >badly<, especially for those of us with older eyeballs (and probably works badly for everyone with any visual difficulties).

>Black< text font on (page-)white background would work far better.

The text on page 198 is (nearly) all such annotations.

The black on white text in your peoples thought bubbles (examples: p 111, p 237, etc.) work much better. No watering eyes.
---
I suspect that formatting and style is shared/standardized across your entire line of books and products. A lot of your folks will hate me. And a lot more will love you just a bit more.

 Alan McGhee  Aug 05, 2022 
Printed Page 91
Diagram

Both, the Decorator class and the ConcreteDecoratorA/ConcreteDecoratorB classes have an own/different instance variable for the component they decorate: Decorator has component and ConcreteDecoratorA/ConcreteDecoratorB have wrappedObj.

These serve the same purpose. Therefore, wrappedObj is superfluous. Instead, ConcreteDecoratorA/ConcreteDecoratorB shall use component.

 Jochen Comes  Jan 02, 2021 
Printed Page 92
Diagram

Same as for diagram on page 91: CondimentDecorator class has instance variable component, whereas Milk, Mocha, Soy, Whip classes have instance variable beverage. The latter is superfluous, Milk, Mocha, Soy, Whip should use component.

 Jochen Comes  Jan 02, 2021 
Printed Page 95
last paragraph

I'm having trouble understanding why class CondimentDecorator is implemented the way it is:

- From the diagram on page 92, I expected CondimentDecorator to have an instance variable named component.
- Consequently, I would not expect the subclasses of CondimentDecorator (see page 97) to have an instance variable named beverage.
- And instead of every concrete subclass of CondimentDecorator have to implement the same constructor logic (see page 97), why not move the constructor logic (this.beverage = beverage (or this.component = component; depending on how the instance variable of class CondimentDecorator will be named)) to the constructor of the abstract class CondimentDecorator?

 Jochen Comes  Jan 02, 2021 
Printed Page 369
method hasNext

You don't need recursion here. In fact, if you use a while loop the code is a lot
easier to understand.

 Anonymous   
Printed Page 374
CompositeIterator

CompositeIterator bug, see also:

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003670

 Anonymous   
Printed Page 377
comments on the stack.peek() method

The comments on the stack.peek() (2 places on the same page, one in next() method, the other in hasNext() method) says '...we get the current iterator off the stack...', peek() method DOES NOT remove the element from the collection. It's simply just getting the element.

 Ivy Chang  Nov 03, 2016 
Printed Page 641
public interface Quackable "extends" QuackObserable"

QuackObservable is an interface but we are extending it like a abstract class

 Maurice Lichtenberg  Mar 02, 2021