Singleton pattern - doubt in Head First Design Patterns book

Question

Hi all,

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.

Answer 3

I believe in that example you only had only ONE Chocolate boiler. And so you should only be able to create one instance of the object representing it. If you were allowed to create multiple instances, you would then perhaps issue the command if (boiler.hotEnough()) boiler.stop() somewhere in you system and would be surprised that although the boiler is already way too hot, it's not stopping because you are talking to some 'dead' instance of a Boiler, which returns hotEnough() : false.

Using the singleton pattern you are making sure that no matter where in your code you say Boiler.getInstance() you will get the one and only boiler object there is, and that when you then talk to it, it will do as you would expect.

Answer 4

The entire example of the chocolateboiler in a singleton bothered me a lot while I was reading it.

On a really fundamental level, I don't see why its necessary when you only have one physical thing, to enforce that fact in software. What happens if you get another one? what are you going to do, add the second to the same singleton? make 2 different singletons? a simple global variable would do the job.

IMO, its not the boiler itself that you can only have one thing of , its access to that particular boiler's controls. You can't allow a second person to start making a new batch of chocolate while its already in that process for someone else, or even allow the same person to make a second batch before the first is finished. From that point of view, a simple queueing or batch processing system would do the job. Using another pattern from the book, the command pattern would be a much better way of handling it , as there's only one waitress , and all new orders get queued up until the cook's done with the current food order. (er, if you haven't seen the book, what I just said might not make much sense, sorry)

Maybe I'm just not getting the point. I haven't done much OOP or anything with design patterns before, and I'm losing job opportunities because of it, so I'm reading up on it.