Singleton pattern - doubt in Head First Design Patterns book

Question

On page 175, there is an example of Chocolate Boiler class. Something like this:

public class ChocolateBoiler {  

  private boolean empty;  
  private boolean boiled;  

  public ChocolateBoiler {  
    empty = true;  
    boiled = false;  
  }  
 // and then three methods to fill, drain and boil which changes the  
 // status of these two flag depending of situation
}  

In section "brain power" they ask a question "How might things go wrong if more than one instance of ChocolateBoiler is created in an application?"

I'm not sure what's the problem with this class. Why do we introduce a singleton pattern here? These two flags are not static and so one per instance. So how creating more than one instance can mess things up?

Answer 1

The question isn't about making an instance of an object.

It's about the confusion caused by having two instances of the object, both of which purport to have the status of the ChocolateBoiler.

If some Object (for example, Cooker) thinks it has the status of the ChocolateBoiler, and some other Object (for example, Recipe) things it has the status of the ChocolateBoiler, what happens now?

Since the variables are instance variables, the ChocolateBoiler objects won't agree on the status of the ChocolateBoiler. Now what happens?

Answer 2

It's only a problem if there only can be one ChocolateBoiler, and if there only can be one, it should be a singleton.