Patrón de Singleton: duda en el libro de patrones de diseño de Head First

Question

En la página 175, hay un ejemplo de la clase de caldera de chocolate. Algo como esto:

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 
} 

En la sección "poder cerebral" hacen una pregunta "¿Cómo podrían las cosas van mal si se crea más de una instancia de ChocolateBoiler en una aplicación?"

No estoy seguro de cuál es el problema con esta clase. ¿Por qué presentamos un patrón singleton aquí? Estos dos indicadores no son estáticos, por lo que uno por instancia. Entonces, ¿cómo crear más de una instancia puede complicar las cosas?

Answer 1

La cuestión no es hacer una instancia de un objeto.

Se trata de la confusión causada por tener dos instancias del objeto, que pretenden tener el estado del ChocolateBoiler.

Si algún objeto (por ejemplo, Cooker) cree que tiene el estado del ChocolateBoiler, y algún otro objeto (por ejemplo, receta) tiene el estado del ChocolateBoiler, ¿qué ocurre ahora?

Dado que las variables son variables de instancia, los objetos de ChocolateBoiler no se pondrán de acuerdo sobre el estado del ChocolateBoiler. Ahora que pasa?

Answer 2

Es solo un problema si solo puede haber un ChocolateBoiler, y si solo puede haber uno, debe ser un singleton.

Answer 3

Creo en ese ejemplo que solo tenía UNA caldera de chocolate. Por lo tanto, solo debería poder crear una instancia del objeto que lo representa. Si se le permitiera crear varias instancias, entonces quizás emita el comando if (boiler.hotEnough()) boiler.stop() en algún lugar de su sistema y se sorprendería de que, aunque la caldera ya está demasiado caliente, no se detiene porque está hablando con una instancia "muerta" de un Caldera, que devuelve hotEnough(): falso.

Utilizando el patrón de singleton, se asegura de que no importa en qué parte de su código diga Boiler.getInstance() obtendrá el único objeto de caldera que existe, y que cuando lo hable, lo hará como es de esperar

Answer 4

Todo el ejemplo del chocolateboiler en un singleton me molestó mucho mientras lo leía.

En un nivel realmente fundamental, no veo por qué es necesario cuando solo se tiene una cosa física, para hacer cumplir ese hecho en el software. ¿Qué pasa si obtienes otro? ¿Qué vas a hacer, agregar el segundo al mismo singleton? hacer 2 singletons diferentes? una simple variable global haría el trabajo.

IMO, no es la caldera en sí misma que solo puede tener una cosa de, es acceso a los controles de la caldera en particular. No puede permitir que una segunda persona empiece a hacer un nuevo lote de chocolate mientras está en ese proceso para otra persona, o incluso permitir que la misma persona haga un segundo lote antes de que termine el primero. Desde ese punto de vista, un simple sistema de cola o procesamiento por lotes haría el trabajo. Usando otro patrón del libro, el patrón de comando sería una forma mucho mejor de manejarlo, ya que solo hay una camarera, y todos los pedidos nuevos se ponen en cola hasta que el cocinero termine con el pedido actual de alimentos. (eh, si no has visto el libro, lo que acabo de decir podría no tener mucho sentido, lo siento)

Tal vez no entiendo el punto.No he hecho mucho POO o nada con los patrones de diseño antes, y estoy perdiendo oportunidades de trabajo por eso, así que estoy leyendo sobre ello.