Modello Singleton - dubbio nel libro Modelli di prima progettazione testa

Question

A pagina 175 c'è un esempio di classe Caldaia al cioccolato. Qualcosa di simile a questo:

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 
} 

Nella sezione "la potenza del cervello" chiedono una domanda: "Come potrebbero le cose vanno male, se si crea in un'applicazione più di un'istanza di ChocolateBoiler?"

Non sono sicuro di quale sia il problema con questa classe. Perché introduciamo un modello singleton qui? Questi due flag non sono statici e quindi uno per istanza. Quindi, come creare più di un'istanza può rovinare tutto?

Answer 1

La domanda non riguarda il creare un'istanza di un oggetto.

Riguarda la confusione causata dall'avere due istanze dell'oggetto, entrambe con lo scopo di avere lo stato di ChocolateBoiler.

Se qualche oggetto (ad esempio, Cooker) pensa che abbia lo stato di ChocolateBoiler e qualche altro Oggetto (ad esempio, Ricetta) ha lo stato di ChocolateBoiler, cosa succede ora?

Poiché le variabili sono variabili di istanza, gli oggetti ChocolateBoiler non concordano sullo stato di ChocolateBoiler. Ora cosa succede?

Answer 2

È solo un problema se può esserci solo un ChocolateBoiler e se ce ne può essere uno solo, dovrebbe essere un singleton.

Answer 3

Credo in quell'esempio che avevi solo UNA caldaia di cioccolato. E quindi dovresti essere in grado di creare solo un'istanza dell'oggetto che la rappresenta. Se ti fosse permesso di creare più istanze, dovresti quindi inviare il comando if (boiler.hotEnough()) boiler.stop() da qualche parte nel tuo sistema e sarei sorpreso che sebbene la caldaia sia già troppo calda, non si fermerà perché stai parlando con qualche istanza "morta" di Caldaia, che restituisce hotEnough(): falso.

Usando il modello singleton ci si assicura che non importa dove nel proprio codice si dice Boiler.getInstance() si otterrà l'unico oggetto della caldaia che c'è, e che quando si parla con esso, lo farà come ti aspetteresti.

Answer 4

L'intero esempio del lanciagranate in un singleton mi ha infastidito molto mentre lo stavo leggendo.

A un livello veramente fondamentale, non vedo perché sia ​​necessario quando si ha solo una cosa fisica, per far rispettare questo fatto nel software. Cosa succede se ne ottieni un altro? cosa hai intenzione di fare, aggiungere il secondo allo stesso singleton? fare 2 diversi singleton? una semplice variabile globale farebbe il lavoro.

IMO, non è la stessa caldaia che si può avere solo una cosa, il suo accesso a controlli di quella particolare caldaia. Non puoi permettere a una seconda persona di iniziare a fare una nuova partita di cioccolato mentre è già in quel processo per qualcun altro, o anche permettere alla stessa persona di fare un secondo lotto prima che il primo sia finito. Da questo punto di vista, un semplice accodamento o un sistema di elaborazione batch farebbe il lavoro. Usando un altro modello del libro, lo schema di comando sarebbe un modo molto migliore di gestirlo, poiché c'è solo una cameriera, e tutti i nuovi ordini vengono messi in coda fino a quando il cuoco non ha finito con l'ordine corrente. (ehm, se non hai visto il libro, quello che ho appena detto potrebbe non avere molto senso, scusa)

Forse non sto ottenendo il punto.Non ho mai fatto molto OOP o altro con modelli di progettazione, e sto perdendo opportunità di lavoro a causa di ciò, quindi sto leggendo su di esso.