Шаблон Singleton - сомнение в книге Head First Design Patterns

Question

На странице 175 приведен пример класса «Шоколадный котел». Примерно так:

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
}  

В разделе «Интеллектуальная мощь» они задают вопрос «Как все может пойти не так, если в приложении создано более одного экземпляра ChocolateBoiler?»

Я не уверен, в чем проблема с этим классом. Почему мы вводим здесь шаблон синглтона? Эти два флага не являются статическими и поэтому один на экземпляр. Так как же создание нескольких экземпляров может испортить ситуацию?

Answer 1

Проблема только в том случае, если может быть только один ChocolateBoiler, и если он может быть только один, это должен быть синглтон.

Answer 2

Вопрос не в том, чтобы создать экземпляр объекта.

Речь идет о путанице, вызванной наличием двух экземпляров объекта, оба из которых имеют статус ChocolateBoiler.

Если какой-то Объект (например, Cooker) считает, что он имеет статус ChocolateBoiler, а некоторые другие объекты (например, Рецепт) имеют статус ChocolateBoiler, что происходит сейчас?

Поскольку переменные являются переменными экземпляра, объекты ChocolateBoiler не согласятся с состоянием ChocolateBoiler. Что теперь происходит?

Answer 3

Весь пример шоколадного котла в синглтоне меня очень беспокоил, пока я его читал.

На самом фундаментальном уровне, я не понимаю, почему это необходимо, когда у вас есть только одна физическая вещь, чтобы закрепить этот факт в программном обеспечении. Что произойдет, если вы получите еще один? что ты собираешься делать, добавить второй к тому же синглтону? сделать 2 разных синглета? простая глобальная переменная сделает эту работу.

IMO, это не сам котел, из которого вы можете иметь только одну вещь, это доступ к управлению этим конкретным котлом. Вы не можете позволить второму лицу начать делать новую партию шоколада, когда он уже находится в этом процессе для кого-то другого, или даже позволить тому же человеку сделать вторую партию до того, как первая будет закончена. С этой точки зрения, простая система очередей или пакетной обработки сделает эту работу. Используя другой шаблон из книги, шаблон команд будет гораздо лучшим способом обработки, так как есть только одна официантка, и все новые заказы будут поставлены в очередь, пока повар не выполнит текущий заказ еды. (э-э, если вы не видели книгу, то, что я только что сказал, может не иметь большого смысла, извините)

Может быть, я просто не понимаю. Я раньше не делал много ООП или чего-то подобного с шаблонами проектирования, и из-за этого я теряю работу, поэтому я читаю об этом.

Answer 4

Полагаю, в этом примере у вас был только ОДИН шоколадный котел. И поэтому вы должны иметь возможность создавать только один экземпляр объекта, представляющего его. Если бы вам было разрешено создавать несколько экземпляров, вы бы, возможно, выполнили команду if (boiler.hotEnough()) boiler.stop() где-нибудь в вашей системе и были бы удивлены, что, хотя котел уже слишком горячий, он не останавливается, потому что вы разговариваете с каким-то «мертвым» экземпляром. котла, который возвращает hotEnough(): false.

Используя шаблон синглтона, вы проверяете, что независимо от того, где в вашем коде вы говорите Boiler.getInstance (), вы получите единственный объект котла, который есть, и что когда вы затем с ним поговорите, он будет делать так: вы ожидаете.