Discussion :

[Le Mérovingien]

Bonjour,

J'ai récemment parcouru le forum C++ et j'ai vu beaucoup de membres "experts" s'insurger contre l'utilisation des singletons en C++, mais je n'ai pas trouvé pourquoi.

J'aimerais donc savoir pourquoi les singletons (que j'utilise de temps à autre) doivent être évités ?
Dans quels cas sont-ils à utiliser et dans quels cas ne le sont-ils pas, et comment les remplacer ?

J'espère que ma question est posée au bon endroit, et pas trop vague. J'ai fait quelques recherches bien sur mais je n'ai rien trouvé là dessus (peut être que je ne savais pas quoi chercher). Je peux fournir quelques exemples de situations où j'ai utilisé les singletons, mais j'aimerais pour commencer avoir un avis global sur la question.

Merci d'avance

[Goten]

La raison est assez simple, un singleton n'est ni plus ni moins qu'une variable globale déguisé. Donc l'analogie est vite faite . Néanmoins dans certains cas ama il est utile de faire ce genre de concession d'autant plus que certaines implémentations sont vraiment excellente. (je pense à celle de loki là).

[jabbounet]

Je pense que ta question est mal posée,

Un singleton peu être très une bonne idée dans certains cas et une très mauvaise dans d'autres.

les singletons existent, il faut simplement savoir quand et comment les utiliser.

Ta question c'est un peu comme être pour ou contre le tournevis dans une boite à outil. tu pourra enfoncer un clou avec mais ce n'est pas sont boulot à la base.

[Jean-Marc.Bourguet]

Le singleton est une forme de variable globale; c'est parfois nécessaire mais c'est tellement une source de couplage et d'ennuis qu'il faut en réduire les utilisations aux cas où c'est nécessaire et pas simplement utiles ou même simplement pratique.

[Le Mérovingien]

Merci pour vos réponses,

Je comprends que le singleton est à utiliser avec précautions, au même titre que les variables globales, et donc je précise ma question, y'a t'il des cas typiques où leur utilisation est bienvenue, où on ne peut pas faire autrement, ou tout du moins des cas où faire autrement serait pire que de les utiliser ?

S'il n'y a pas de cas typiques tant pis, je ne demande pas un troll

[jabbounet]

Merci pour vos réponses,

Je comprends que le singleton est à utiliser avec précautions, au même titre que les variables globales, et donc je précise ma question, y'a t'il des cas typiques où leur utilisation est bienvenue, où on ne peut pas faire autrement, ou tout du moins des cas où faire autrement serait pire que de les utiliser ?

S'il n'y a pas de cas typiques tant pis, je ne demande pas un troll

Ce qui est bien avec l'informatique c'est qu'il y'a souvent plusieurs efficaces façon de résoudre un problème. je sais cela ne répond pas a ta question

[nouknouk]

y'a t'il des cas typiques où leur utilisation est bienvenue

Le cas typique est amha celui où:

- on a besoin d'un même composant à plein d'endroits différents du programme, y compris dans des modules séparés.

- on est absolument certain que ce composant n'a de raison d'être qu'en étant unique quoi qu'il advienne dans l'évolution du programme.

Cela équivaut à élire les cas où l'utilisation d'une autre technique demanderait trop d'efforts comparés au singleton (dans le sens: "le singleton étant plutôt un anti-pattern, on doit l'envisager uniquement quand les autres techniques ont montré leurs limites").

Il faut en effet garder à l'esprit qu'un singleton pourra toujours être remplacé par une autre technique. Le tout est de cerner les cas spécifiques où les autres techniques seront trop lourdes à mettre en place comparé au singleton.

Ceci étant dit, tout dépend du contexte. Un exemple x pourra être pertinent dans un cas de figure tandis qu'il pourra être démonté par une personne tierce en te montrant que pour le même concept mais dans un autre contexte, l'utilisation d'un singleton sera source d'ennuis.

Bon, j'ai assez tourné autour du pot. Je me lance (affutez vos armes ) pour un exemple qui vaut ce qu'il vaut.

Un système de pool de ressources utilisées en shadow copy pour économiser de la mémoire:

J'ai un programme qui utilise beaucoup d'images bitmap (icônes, ...) et surtout beaucoup de fois la même image. Si j'utilise 500 fois l'image de l'icône "point d'interrogation". Au lieu de faire une 'deep copy' de l'icône pour chaque endroit où elle est utilisée, on utilise toujours la même référence à cette unique icône. Tu économises 499 fois la place prise en mémoire par ton icône.
A utiliser en parallèle d'un système de "copy-on-write" lors de la modification d'une icône sur les 500.

Dans ce cas là, un système centralisé de gestion des images 'en cache' peut-être intéressant. Ca sent typiquement l'implémentation statique du pool dans ta classe image, ce qui revient peu ou prou au même qu'un Singleton.

Ce genre de cas peut être décliné dans beaucoup de domaines où une gestion centralisée d'une ressource (qui est utilisée à différents endroits) est bienvenue (pour des raisons d'optimisation notamment). Un pool de Thread, un pool de connexions réseau, la gestion des logs, ...

[Le Mérovingien]

D'accord, merci pour cette réponse.

Voila le cas où j'ai utilisé un singleton : j'ai créé un gestionnaire de log, qui me permet d'ajouter des messages de log quand et où j'en ai envie, de façon homogène. Le gestionnaire peut être parametrer pour utiliser un fichier, une sortie standart ou n'importe quel ostream comme destination pour les log, cette propriété étant constante (dans le sens où on la déclare une fois, et elle est active tout le temps, jusqu'à ce qu'on la change). On peut aussi sélectionner d'autres valeurs par défaut, comme le niveau de verbosité ou le niveau d'importance des messages (info, warning, erreur, ...).
Cette classe est donc un singleton, et je peux l'appelée partout où je veux.

Est ce que l'utilisation d'un singleton dans ce cas vous parait justifiée ? Et si non que proposez vous ?

Je peux poster le code de cette classe (avec la doc) si celà peut être utile.

Merci d'avance

[nouknouk]

C'est effectivement un cas typique d'une ressource centralisée qui doit être accessible de beaucoup d'endroits différents.

A titre d'info, le mécanisme de logs standard de Java utilise d'ailleurs la même approche, avec une fonction statique pour récupérer un objet permettant d'enregistrer des logs. Cf. la classe Logger et sa fonction getLogger. Le Logger de Java propose pas mal de rafinements intéressants à découvrir, et qui pourront peut-être te donner quelques idées

[Le Mérovingien]

@nouknouk : très intéressant ce lien vers les logger java, et je suis content j'ai retrouvé une partie de ce que j'ai fait, la seule différence c'est que j'utilise la surcharge de l'opérateur <<, c'est tellement pratique, mais, bref, là n'est pas le sujet .

J'utilise également un singleton pour implémenter un gestionnaire d'utilisateurs, mais là je suis beaucoup moins sur de la pertinence de ce choix.

J'ai une classe User, qui implémente des utilisateurs non copiables, mais il existe un constructeur avec paramètres obligatoires public (les autres constructeurs et l'operateur =() sont privés).
J'ai également une classe UserManager qui contient une map d'utilisateurs, avec un identifiant uid associé à chaque utilisateur (j'utilise uid comme clé pour ma map). Ce UserManager propose 3 méthodes principales, addUser() qui ajoute un utilisateur en vérifiant au préalable qu'il n'existe pas déjà (pas le meme nom en gros), delUser qui supprime un utillisateur, et getUser qui retourne une référence sur un utilisateur (et lève une exception si l'utilisateur n'existe pas). J'ai implémenté ce UserManager avec un singleton, mais je me pose des questions : n'y aurait-il pas un moyen de gérer l'ensemble des utilisateurs directement à partir de la classe User, sans utiliser de UserManager, ce qui me permettrait de supprimer le singleton, et de stocker directement un pointeur (shared_ptr ?) quand j'en ai besoin, et de pouvoir créer un utilisateur "unique" sans passer par un Manager ? J'ai cherché un pattern pouvant faire ça, mais je n'ai pas trouvé. J'ai bien sur pensé à inclure une map static dans la classe User, mais je ne sais pas si c'est bien. Qu'en pensez vous ? Y'a t'il une solution propre pour faire celà ?

Je ne sais pas si j'ai été très clair, donc n'hésitez pas à demander des précisions si besoin.

[nouknouk]

J'utilise également un singleton pour implémenter un gestionnaire d'utilisateurs, mais là je suis beaucoup moins sur de la pertinence de ce choix.

Je serais en effet beaucoup plus réservé - à priori - sur l'utilisation d'un singleton dans ce cas précis.

En effet, si on reprend les deux conditions du "cas typique", on a:

- "on a besoin d'un même composant à plein d'endroits différents du programme" => Contrairement à un outil de log qui va être potentiellement utilisé dans presque toutes les classes, la gestion des utilisateurs est en règle générale beaucoup plus ciblée à certaines parties précises de l'application.

- "on est absolument certain que ce composant n'a de raison d'être qu'en étant unique" => Et si demain tu veux évoluer vers plusieurs pools d'utilisateurs, organiser les utilisateurs par groupes, etc... la changement dans ton implémentation risque d'être alourdi par le choix du singleton.

Ceci étant dit, comme le précisait jabbounet, il y a dans 99% des cas plusieurs approches différentes pour arriver à ses fins

[jabbounet]

en tout cas il ne faut surtout pas faire d'écriture concurrentielle dessus dans une appli multithreadé.

goulet d'étranglement assuré.

[Jean-Marc.Bourguet]

Je comprends que le singleton est à utiliser avec précautions, au même titre que les variables globales, et donc je précise ma question, y'a t'il des cas typiques où leur utilisation est bienvenue, où on ne peut pas faire autrement, ou tout du moins des cas où faire autrement serait pire que de les utiliser ?

Je vais te conseiller de partir sur une autre voie: comprend quels sont les problèmes posés par les variables globales, comprends les avantages et les inconvéniants des alternatives, tu seras alors capable de choisir en connaissance de cause. Comme dans toute affaire de conception, le contexte joue beaucoup.

En passant, on peut toujours s'en passer, au prix d'arguments supplémentaires.

En passant toujours -- et pour apporter un argument en faveur de leur utilisation, les choix de conceptions c'est souvent des compromis --, un problème potentiel de pas mal d'alternatives, est qu'on finit par avoir des chemins d'accès différents au même objet -- celui qui est candidat à être singleton. Et que comme tous les chemins référencent le même objet, on ne détecte pas qu'on les utilise de manière inconsistante. Ce qui peut être plus problématique pour l'évolution de d'être partit sur un singleton (pour commencer on sous-estime le coût d'utiliser réellement plusieurs objets -- le travail est déjà fait, n'est-ce pas?, on n'a pas utilisé de singleton).

[Le Mérovingien]

@jabbounet : tu parles des Logger Java ou des singletons en général ?

Merci à tous pour vos réponses, je me suis rappelé hier soir pourquoi j'avais besoin d'un singleton, ou d'une variable globale : mon appli est un serveur qui utilise RPC, et je n'ai pas trouvé comment passer le gestionnaire d'utilisateurs dans les fonctions que le serveur appellent : elles ont un prototype fixe qui ne prévoit pas de champs utilisateurs (void* par exemple). Si quelqu'un à la solution sans variable globale je suis preneur.

Mais comme ce n'est pas le sujet de ce post, je vais le mettre en résolu, et si un jour je veux essayer de suprimer ces variables globales, j'en ouvrirai un autre.

Merci et à bientôt

[jabbounet]

@jabbounet : tu parles des Logger Java ou des singletons en général ?

Merci à tous pour vos réponses, je me suis rappelé hier soir pourquoi j'avais besoin d'un singleton, ou d'une variable globale : mon appli est un serveur qui utilise RPC, et je n'ai pas trouvé comment passer le gestionnaire d'utilisateurs dans les fonctions que le serveur appellent : elles ont un prototype fixe qui ne prévoit pas de champs utilisateurs (void* par exemple). Si quelqu'un à la solution sans variable globale je suis preneur.

Mais comme ce n'est pas le sujet de ce post, je vais le mettre en résolu, et si un jour je veux essayer de suprimer ces variables globales, j'en ouvrirai un autre.

Merci et à bientôt

Des singletons, si tu as 5 thread qui doivent écrire sur le même objet, il vont devoir se le partager par exemple ce n'est pas grave s'ils ecrivent dessus un fois tous les 10 ans. cela deviens problématque quand tu en fait plusieurs (centaine de) milliers par seconde, il s'agit souvent d'une erreur de conception à la base (le singleton n'avait pas forcement besoin d'exister, un autre choix de conception aurait été meilleur).

[Le Mérovingien]

Oui c'est vrai, mais pour ma gestion des utilisateurs, si je passais un unique UserManger par référence, sans singleton, j'aurais le meme problème non ?