Singleton pattern - doute dans Head First Design Patterns book

Question

Sur la page 175, il y a un exemple de classe Chocolate Boiler. Quelque chose comme ceci:

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 
} 

Dans la section « pouvoir du cerveau » ils posent une question: « Comment peut les choses tournent mal si plus d'une instance de ChocolateBoiler est créé dans une application? »

Je ne sais pas quel est le problème avec cette classe. Pourquoi introduisons-nous un motif singleton ici? Ces deux indicateurs ne sont pas statiques et donc un par instance. Alors, comment créer plus d'une instance peut gâcher les choses?

Answer 1

La question ne concerne pas la création d'une instance d'un objet.

Il s'agit de la confusion causée par deux instances de l'objet, toutes deux censées avoir le statut de ChocolateBoiler.

Si un objet (par exemple, Cooker) pense qu'il a le statut de ChocolateBoiler et d'autres objets (par exemple, Recette), il a le statut de ChocolateBoiler, que se passe-t-il maintenant?

Puisque les variables sont des variables d'instance, les objets ChocolateBoiler ne seront pas d'accord sur l'état du ChocolateBoiler. Maintenant qu'est-ce qui se passe?

Answer 2

C'est seulement un problème s'il ne peut y avoir qu'un seul ChocolateBoiler, et s'il n'y en a qu'un, il devrait s'agir d'un singleton.

Answer 3

Je crois que dans cet exemple, vous n'aviez qu'une seule chaudière au chocolat. Et ainsi vous devriez seulement pouvoir créer une instance de l'objet le représentant. Si vous étiez autorisé à créer plusieurs instances, vous pourriez alors émettre la commande if (boiler.hotEnough()) boiler.stop() quelque part dans votre système et vous seriez surpris que bien que la chaudière soit déjà trop chaude, elle ne s'arrête pas parce que vous parlez à une instance «morte» d'un Chaudière, qui renvoie hotEnough(): false. En utilisant le modèle singleton vous vous assurez que peu importe où dans votre code vous dites Boiler.getInstance() vous obtiendrez le seul et unique objet chaudière qui existe, et que lorsque vous lui parlerez, cela fera comme vous vous y attendriez.

Answer 4

L'exemple complet de la chocolaterie dans un singleton m'a énormément dérangé pendant que je le lisais.

Sur un niveau vraiment fondamental, je ne vois pas pourquoi c'est nécessaire quand vous n'avez qu'une seule chose physique, pour appliquer ce fait dans le logiciel. Que se passe-t-il si vous en obtenez un autre? qu'allez-vous faire, ajouter la seconde au même singleton? faire 2 singletons différents? une variable globale simple ferait l'affaire.

IMO, ce n'est pas la chaudière elle-même que vous ne pouvez avoir qu'une chose, son accéder aux contrôles de cette chaudière particulière. Vous ne pouvez pas permettre à une deuxième personne de commencer à faire un nouveau lot de chocolat alors qu'elle est déjà dans ce processus pour quelqu'un d'autre, ou même permettre à la même personne de faire un deuxième lot avant la fin du premier. De ce point de vue, un simple système de mise en file d'attente ou de traitement par lots ferait l'affaire. En utilisant un autre motif du livre, le motif de commande serait une meilleure façon de le manipuler, car il n'y a qu'une seule serveuse, et toutes les nouvelles commandes sont mises en file d'attente jusqu'à ce que le cuisinier ait fini avec l'ordre de cuisson actuel. (heu, si vous n'avez pas vu le livre, ce que je viens de dire pourrait ne pas avoir beaucoup de sens, désolé)

Peut-être que je ne comprends pas.Je n'ai pas fait beaucoup de POO ou quoi que ce soit avec des modèles de design auparavant, et je perds des opportunités d'emploi à cause de cela, alors je suis en train de lire dessus.