Head First Design Patterns
by Eric Freeman, Elisabeth Freeman with Kathy Sierra, Bert Bates

The unconfirmed error reports are from readers.  They have not yet been 
approved or disproved by the author or editor and represent solely the
opinion of the reader.

Here's a key to the markup:
        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification

This page was updated June 13, 2008.


UNCONFIRMED  errors and comments from readers: 


[5 or 35]  Sharpen your pencil;
Sharpen your pencil on page 5 asks "Which of the following are disadvantages of using
inheritance to provide Duck behaviour."

whereas

Sharpen your pencil answers on page 35 are for the question "Which of the following
are disadvantages of using subclassing to provide specific Duck behaviour."

The answers are not correct for the exercise on page 5!


[59]  weatherData.registerObserver(this);
Registering a listener from its constructor allows the "this" reference to escape
potentially causing concurrency issues.

http://www-128.ibm.com/developerworks/java/library/j-jtp07265/index.html


(67) Number 3;
Instead of:
so we've removed the code for register, add and notify

it should be:
so we've removed the code for register, remove and notify


[95] bottom;
The implementation of the class CondimentDecorator does not conform to the UML diagram for 
the Decorator pattern available on page 91.

In page 91, the UML diagram shows that Decorator *has a* Component, since there is a 'has a' arraw 
from Decorator pointing to Component.

In page 92, there is another UML diagram of the Decorator pattern that is adapted to the Starbuzz 
case, and it also shows a 'has a' relationship between CondimentDecorator and Beverage.

If the implementation of CondimentDecorator in page 95 were conforming to the Decorator pattern 
diagrams in pages 91 and 92 it would be:

/**
* Implementation of CondimentDecorator conforming to pg 91 UML
* diagram of the Decorator pattern
*/
public abstract class CondimentDecorator extends Beverage {
Beverage beverage; // <-- It should have a Beverage instance
// variable to conform to the 'has a'
// relationship shown in the Diagram in pg 91.

/**
* And providing a constructor like this would be adequate:
*/
public CondimentDecorator(Beverage beverage) {
this.beverage = beverage;
}

public abstract String getDescription();
}

The current implementation of CondimentDecorator in page 95 does not conform to the 
UML definitions presented in pages 91 and 92, what lets the reader with a confusing 
sensation like: "Wasn't I supposed to implement what is shown in the UML diagram definition?", 
or "i believe that 'has a' relationship show in the UML can be omitted if I want...".

For your convenince I'm pasting bellow the current implementation of the CondimentDecorator 
class currently presented in the book:

public abstract class CondimentDecorator extends Beverage {
public abstract String getDescription();
}

Please fix that.


(97) Number 2 at the right;
It is write "to to" instead of "to" : Here, we're going to to pass the beverage ...


(100) 2nd handwritten comment from top;
There is a period missing at the end of the first line.
"FileInputStream is the component that's being decorated The Java I/O..."


[302] 3rd paragraph;
On the method compareTo you receive object as parameter and then you make an explicit cast 
from object to Duck. But if it was not a Duck ? If it is another kind of object? I thought you 
should first test if it is from a compatible type of Duck and then you make the cast.


[368]  method createIterator in class Menu;
The code is buggy.  (That is why the desserts show up multiple times on p374.)  The
reason is that your are creating a new CompositeIterator. When you combine that with
the stack.push statement in method next on p369, you wind up with multiple stacks,
which cause the incorrectly repeated items.

The other problem with your code is that the external iterator doesn't return the
top-level node of the composite. (I.e. your "all-menus" node doesn't get returned.)

These two problems are related.  You aren't distinguishing between the iterator
method that the client calls externally, from the createIterator method that gets
called recursively inside the code.


{369}  method next;
The test
     if (component instanceof Menu)
is not necessary, and is in fact incongruous with your insistence on transparency.
Moreover, this test keeps your code from needing to use null iterators.


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


[374]  CompositeIterator;
CompositeIterator bug, see also:

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


(390) 1st paragraph;
In the last sentence of the paragraph you're writing about having to implement an "empty gumball 
condition" I think this should be an "empty gumballmachine condition"


(397) textballoon;
The last sentence says "not to mention that CEO will drive us crazy."
I'm not sure since English is not my native language, but I think this should be something like "not to 
mention that the CEO will drive us crazy."


(398) Textballoon;
First sentence:
"Now we're going put all the behavior..."
should be:
"Now we're going to put all the behavior..."


{403} GumballMachine member variable declaration;
State state is initialized with soldOutState. However, soldOutState is null at that point. 
So, if GumballMachine is instantiated with numberGumballs==0, this.state will remain null 
rather than an object of class SoldOutState. That's probably not what was intended.


[465] paintIcon code;
The code is not thread safe for all the reasons you list in the singleton pattern pg 182 .

The ImageIcon reference should be volatile and use java 1.5 + or accessed via synchronized getters and 
setters for all Java versions. The issue is its initialised by one thread, written two by another and 
then read again by potentially more threads but certainly not the second that loads it.

If you don't in theory the 2nd thread can never see the loaded icon, or see the reference but only the 
result of all or part of its construction i.e. you do not have correct memory barriers and therefore no 
happens before ordering.

[You also want imageURL to be final post Java 1.4 for the same reasons]


(471) middle column, top paragraph;
"If they were coupled the client would have to wait until each image is retrieved before it could paint 
it entire interface." 

should be:

"If they were coupled the client would have to wait until each image is retrieved before it could paint 
its entire interface."


[565]Code Method on() of the class BeatModel;
In order to have the MIDI sound output play continuously you should add the line sequencer.setLoopCount(sequencer.LOOP_CONTINUOUSLY); before starting the sequencer.

Sample program src/headfirst/combined/djview/BeatModel.java;

So

public void on() {
sequencer.start();
setBPM(90);
}

should be :

public void on() {
sequencer.setLoopCount(sequencer.LOOP_CONTINUOUSLY);
sequencer.start();
setBPM(90);
}


{613}class "ConcreteRemote" in UML class diagram;
In the first edition (October 2004), class "ConcreteRemote" in UML class diagramm for the "Bridge" pattern on page 613 contains a method "setStation()". However, I would expect that the method shall be named "setChannel()".