/ Conséquence de Singleton - design-patterns, singleton

La conséquence de Singleton - design-patterns, singleton

J'apprends le motif Singleton en utilisant le livre de GoF. J'ai un problème quand je lis sa conséquence:

  • Plus flexible que les opérations de classe: Une autre façon de conditionner un singletonla fonctionnalité consiste à utiliser des opérations de classe (c'est-à-dire des fonctions membres statiques en C ++ ou des méthodes de classe en Smalltalk). Mais ces deux techniques de langage rendent difficile la modification d’un plan afin d’autoriser plus d’une instance de classe. De plus, les fonctions membres statiques en C ++ ne sont jamais virtuelles et les sous-classes ne peuvent donc pas les remplacer de manière polymorphe.

Je ne comprends vraiment pas cette explication. Je pense que le fonctionnement des classes (méthode statique) peut également autoriser plus d’une instance d’une classe si j’utilise une liste statique d’instances, mais je sais que je me trompe, bien sûr.

Alors, n'importe qui peut me donner des exemples pour m'aider à comprendre ce problème? Merci beaucoup!

Réponses:

0 pour la réponse № 1

L’idée de départ est d’utiliser uniquement des membres statiques dans la classe et des méthodes statiques qui ne fonctionnent que sur ces membres statiques, puis d’utiliser la classe elle-même en tant que singleton. Aucune interdiction d'exécution n'est requise ou autorisée - et si vous effectuez une modification, il s'agit d'un autre type (une instance, pas une classe. Dans Smalltalk, il s'agit d'une instance d'une classe et non d'une instance d'une métaclasse).

Ainsi, si vous gérez une liste de telles instances, vous ne créez pas plusieurs instances de ce type. vous avez créé un singleton (la classe) qui a en cela liste d'instances de type non singleton.

En un sens, chaque classe est un singleton. C’est juste que ce n’est généralement pas une bonne idée d’en utiliser un comme objet singleton dans votre programme, pour les raisons mentionnées dans le texte.