Discussion :

[NoIdea]

Là est l'erreur, on ne peut jamais en être sûr.

En effet, on peut rarement être sur. Cependant, comme je l'ai dit plus haut, je ne suis pas la meilleur personne pour argumenter en faveur des singletons. Je dis juste qu'il doit y avoir au moins un cas où ce design est justifié.

Et si elle n'évolue pas, ça n'aura pas coûté cher de réfléchir un peu pour bien la concevoir sans singleton.

Sa dépend du niveau du programmeur. Mais tu as raison dans la majorité des cas.

Jusqu'au jour où tu auras deux écrans, et tu te diras "tiens, et si j'utilisais la seconde pour afficher une autre vue, par exemple une vue en fil de fer, ou le zbuffer, ou des infos de performance ?"

En effet.

Et le coup du GetInstance(int fenetre) suppose qu'en fait, tu crées plusieurs instances du même objet.

Oui.

Ce qui, pour un singleton, serait tout à fait original

C'est le gestionnaire de contexte OpenGL qui est singleton, plus le contexte.

[guillaume07]

Moi j'avoue ne pas savoir comment me passer de singleton quand par exemple dans une appli j'ai

• un logger
• une liste dabonnement
• une liste de connexion style socket
• une connexion à une Bdd
• une liste d'objet métier (par exemple une liste d'ordre boursier)

Tous ces objets listes sont uniques et doivent a priori être appelable à droite et à gauche dans l'appli: dans la gui dans le core engine etc

Ma solution est d'avoir une classe 'main' singleton qui possède en membre donné tous les objets listes , et qui est déclarée comme étant un singleton... ce qui rend indirectement tous les autres objets listes singleton

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
class Main
{
boost::mutex mutex_;
 
ListeAbonnement listeAbo_;
ListeOrdre listeOrdre_;
ListeConnexion listeCnx_;
 
public:
static Main& pInstance()
{
static Main main;
return main;
}
 
...getter....
 
};

je ne vois pas trop comment je pourrais faire d'autre étant donné, que ces listes doivent être accessible dans les différents thread à savoir

• les thread socket
• le thread de la gui
• le thread de la Bdd
• les thread de calcul

[LittleWhite]

Moi j'avoue ne pas savoir comment me passer de singleton quand par exemple dans une appli j'ai

• un logger
• une liste dabonnement
• une liste de connexion style socket
• une connexion à une Bdd
• une liste d'objet métier (par exemple une liste d'ordre boursier)

Tous ces objets listes sont uniques et doivent a priori être appelable à droite et à gauche dans l'appli: dans la gui dans le core engine etc

Ma solution est d'avoir une classe 'main' singleton qui possède en membre donné tous les objets listes , et qui est déclarée comme étant un singleton... ce qui rend indirectement tous les autres objets listes singleton

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
class Main
{
boost::mutex mutex_;
 
ListeAbonnement listeAbo_;
ListeOrdre listeOrdre_;
ListeConnexion listeCnx_;
 
static Main& pInstance()
{
static Main main;
return main;
}
 
};

je ne vois pas trop comment je pourrais faire d'autre étant donné, que ces listes doivent être accessible dans les différents thread à savoir

• les thread socket
• le thread de la gui
• le thread de la Bdd
• les thread de calcul

Il semble que vous devriez vous pencher sur le design pattern du MVC. Enfin crois.

[guillaume07]

Dans le cas du MVC où serait instancié les objets Vue/controleur/Modele? dans le main , en variable globale(=singleton) , ailleurs ?

l'avantage de mon architecture est la simplicité pour gérer les problèmes de multithreading (accés concurrentiel/deadlock), mais je pense malgrès tout qu'il y a matière à mieux faire.

EDIT: J'imagine dans le main et on passe un pointeur à chacun des objets, mais quel serait l'avantage à avoir une architecture comme ça ?

[Mat007]

J'imagine dans le main et on passe un pointeur à chacun des objets, mais quel serait l'avantage à avoir une architecture comme ça ?

C'est presque une question de philosophie.

En inversant le flux de communications entre les objets (tell don't ask), tout le reste se met en place de lui-même (Demeter, programmer sur des interfaces, separation of concerns, etc..) et facilite beaucoup de choses (les tests unitaires, l'ajout de fonctionnalités, les remaniements, etc..).

Et les singletons, ben... ça va juste pas du tout avec tout ça...

MAT.

[guillaume07]

C'est presque une question de philosophie.

MAT.

c'est tout à fait ma vision des choses, test unitaire je n'utilise pas du coup avec ma façon de faire je ne sais pas si c'est réellement limitant ou si c'est juste bullshit que de dire singleton + test unitaire = 0

[Emmanuel Deloget]

c'est tout à fait ma vision des choses, test unitaire je n'utilise pas du coup avec ma façon de faire je ne sais pas si c'est réellement limitant ou si c'est juste bullshit que de dire singleton + test unitaire = 0

Dans les tests unitaires, par définition, tu souhaite tester une unique chose à chaque fois. Si tu mixes un singleton dans tout ça, ton singleton va enregistrer des états qui peuvent rendre tes tests invalides, donc non pertinents, et donc te cacher des bugs que tu aurais découvert sans un cache global (puisque le singleton rempli grosso-modo cet office).

[Klaim]

Quand on veut représenter l'interface d'une partie de l'environnement (hardware ou pas) qui as un état dans notre espace mémoire, je ne vois pas comment faire autrement que d'utiliser un singleton.

Personnellement je n'en utilise jamais sauf pour ce cas là.

Appliquer le pattern MVC dans ce genre de cas c'est se compliquer la vie et dans certains cas rendre le code plus lent que nécessaire.

[Emmanuel Deloget]

Quand on veut représenter l'interface d'une partie de l'environnement (hardware ou pas) qui as un état dans notre espace mémoire, je ne vois pas comment faire autrement que d'utiliser un singleton.

Personnellement je n'en utilise jamais sauf pour ce cas là.

Appliquer le pattern MVC dans ce genre de cas c'est se compliquer la vie et dans certains cas rendre le code plus lent que nécessaire.

C'est l'idée derrière std::cout ; ceci dit, je verrais plus un monostate qu'un singleton. Au niveau de l'implémentation, c'est très similaire (pour simplifier, le getInstance est fait en interne dans le monostate). Mais au niveau de l'utilisation, le monostate est plus clair (ne serait'ce que parce qu'on a plus ces getInstance).

Ensuite, une variable globale est une solution acceptable dans ce cas, en mettant quelques limites.

[Klaim]

Hmm je crois qu'on est encore retombé sur le souci du sens de singleton et de ses différentes implémentations...

En fait dans mon cas j'utilise une implémentation qui ressemble a une variable globale mais c'est tout le type qui ne peut être instancié qu'une fois (parcequ'il n'y a donc qu'un système) et surtout la création et la destruction de cette instance sont déterministes (je n'utilise pas une version qui crée l'instance la première fois qu'on la récupère, mais plutot des fonctions de creation et destructions explicites pour que l'utilisateur ait un controle clair de la vie de l'instance, surtout lors d'allocations. Et aussi permettre la destruction + creation si nécessaire).

Donc en fait on est d'accord je crois. std::cout est instancié dés le départ de l'application il me semble, ça serait la principale différence, sauf que le type de cout peut être instancié plusieurs fois non?

[Goten]

Donc en fait on est d'accord je crois. std::cout est instancié dés le départ de l'application il me semble, ça serait la principale différence, sauf que le type de cout peut être instancié plusieurs fois non?

Oui et oui.

[Jean-Marc.Bourguet]

Pour accéder à un état global, on a le choix: soit on le reçoit en paramètre, soit on le trouve avec un nom bien connu.

L'utilisation d'un nom bien connu (que ce soit variable globale, structure de donnée abstraite, singleton, monostate,... fondamentalement ce ne sont jamais que des variantes, ma préférence en général va à la structure de donnée abstraire mais ça me semble plus une préférence stylistique qu'autre chose) est problématique en particulier en matière de tests, et d'évolution (l'état qu'on pensait global et unique ne le reste pas toujours, entre autres quand on ajoute des threads).

Le recevoir en paramètre n'a pas ces inconvénients. Mais en a d'autres. Il impose à l'appelant de connaître cette dépendance. En maintenant (pour une définition de maintenance qui comprends les évolutions majeures sur un produit existant depuis longtemps), ça peut être quand même fortement invasif (c'est en gros le même problème que les spécifications d'exception, il faut toujours toucher tous les intermédiaires). Et si ça se multiplie un peu trop, on finit par les regrouper et par les stocker. En regroupant, on récupère les problèmes du nom unique car on réintroduit le couplage qu'on voulait supprimer. En stockant, on finit par avoir plusieurs noms pour la même chose, noms qu'on va utiliser plus ou moins indifféremment car on n'a pas de bon critère pour savoir lequel utiliser. Et quand le moment de l'évolution arrive, si mon expérience est extrapolable, vérifier que le bon nom a chaque fois été bien choisi est presque aussi coûteux que de faire l'évolution à partir du nom unique. Sauf que ce ne sera pas planifié comme partie de l'évolution. Remplacer une hypothèse explicite par une hypothèse implicite, c'est pas bon.

[guillaume07]

monostate

Quand tu parles de monostate, c'est ce que d'autre appel stateless ?

[Flob90]

Le dp monostate c'est ca : http://www.informit.com/guides/conte...lus&seqNum=147 (j'ai pas trouvé mieux comme exemple). Un des problèmes étant l'initialisation des données.

Une classe stateless ca veux juste dire qu'elle n'a pas d'état (pour faire simple, tu prends n'importe quel instance de cette classe, elles représentent toutes la même chose, le même état).

Donc en effet le pattern monostate va reposer sur des classes stateless, mais ca peut aussi être le cas d'autre éléments : singleton, allocateur, ...

@klaim: Tout comme std::cout, si ton singleton est non intruisif tu pourras aussi créer d'autre objet du même type.

[guillaume07]

bon moralité j'ai l'impression qu'il n'y a pas vraiment d'alternative extra pour le singleton, l'éviter je veux bien, mais bon ça reste fort pratique et simple.

[Flob90]

A première vue, j'ai l'impression que tout ce qui est décrit comme "préoccupation transversale" en programmation par aspect (cf http://skebir.developpez.com/tutoriels/java/aspectj/), est plus ou moins sujet à être un bon singleton.

Mais d'un autre coté, c'est surtout la facon de penser son programme qui amène à ce genre de design, dans une optique plus "C++" (ou programmation par objet "classique"), on essaie d'éviter l'apparition de "préoccupation transversale", de ne pas avoir de code qui sert partout.

Et je crois comprendre, en lisant son article, que c'est sur ce point que Emmanuel dit ne pas voir d'utilisation au singleton : pas de nécessité d'avoir à la fois un point d'accés global et une garantie d'unicité en même temps.

@Emmanuel: Pour un pool mémoire utilisé par un allocateur, tu ferais comment ? Monostate et initialisation au démarrage de l'appli ?

@guillaume07: 7 objets qui peuvent être utilisés n'importe où dans le code ca sent quand même le problème de conception. En avoir un ou deux et ne pas réussir à facotoriser ca peut être normal, mais avoir tout le coeur de l'application c'est quand même étrange. Et d'autre part ta classe main ne devrait pas être à mon avis, elle ne respecte pas le SRP.

Et tu parles de thread, mais n'oublie pas que MT et singleton c'est un problème qui n'est pas trivial, soit tu créés ton instance avant d'entrer dans les thread, soit tu mets en place quelque chose à base de CAS qui doit être une solution viable (mais c'est pas si évident que ca il me semble, par contre c'est lock-free et bien fait peut-etre wait-free).

Et enfin, tu as besoin d'accéder aux listes dans les différents thread, le problème c'est que si les listes sont aussi lié qu'elles semblent l'être, il risque d'y avoir beaucoup d'accés concurrentiel, et ca c'est pas bon, les mutex (ou autre) c'est pratiques, mais si il y en a trop ca sera pas plus performant qu'en non threader, AMHA.

[guillaume07]

@guillaume07: 7 objets ...

Bon à savoir que ça marche nickel avec cette implémentation, et que je l'ai fait en un temps relativement court, maintenant c'est vrai que j'aurais été curieux de faire du code review sur l'appli

[screetch]

@flops: un pool mémoire est global certes, mais pas unique, donc ca ne devrait pas être un singleton.
le fait qu'il n'en existe qu'un pour un code donné n'est pas la donnée critique: c'est le fait qu'il ne peut pas y en avoir deux, jamais.

dans mon appli il y a de multiples instances de pools mémoire, pour augmenter la proximité entre les objets du même type; par exemple, tous les objets créés par les scripts LUA sont alloués avec un pool
au final, chaque pool appèle juste malloc (donc l'implémentation n'est pas faite) mais l'interface permet bien d'avoir plusieurs pools.

@guillaume: c'est a la limite de l'irresponsabilité (je ne veux pas dire que tu es irresponable desolé pour la formulation) tes objets devraient avoir un autre objet responsable mais il n'y en a pas. Par exemple, qui est chargé d'établir la communication réseau, de détecter en cas de lag ou de deconnexion, etc etc. Tes objets n'ont plus de responsable et ca c'est dommageable sur certains plans.
En général ce sont des techniques qui vont péter a la gueule en cas de refactoring ou en cas de découverte d'un problème (exemple: crash si la connexion tombe, tu vas peut-être devoir refactoriser)

le design pattern singleton selon moi est dommageable dans la plupart des cas; et j'avoue être comme emmanuel, j'ai toujours trouvé mieux a faire

[Klaim]

@klaim: Tout comme std::cout, si ton singleton est non intruisif tu pourras aussi créer d'autre objet du même type.

Pas si l'objet, comme dans mes cas d'utilisation, représente un unique système de l'environnement (avec un etat . Par exemple l'acquisition des entrées (clavier/souris/autre pour du jeu par exemple). Il y a un objet par materiel (donc plusieurs instances), mais il n'y a qu'un objet qui les détiens tous, les mes a jour etc.(donc une seule instance). Permettre plusieurs instances pour ce dernier objet serait simplement permettre que des érreurs alors qu'elles sont facile à eradiquer (en n'ayant qu'un seul objet).

Si j'avais une classe qui en réalité faisait figure d'interface pour le même objet (un peu comme des classes de connexion a des bases de données) alors ça serait une solution, sauf que :

1. dans mes cas d'utilisation, ces objets n'auraient pas d'état, seraient uniquement des proxy, donc je perdrais inutilement un peu de mémoire a chaque instanciation;
2. changer l'interface de l'objet unique qui détiens les données force a répercuter les changement sur la/les classes proxy, pour tout ce qui est publique du moins;
3. d'un point de vue communication aux autres développeurs, ce n'est pas du tout du tout clair (sauf dans le cas de l'objet de la base de donnée, mais on sait tous qu'il aura des infos locales et qu'il y aura des transactions ensuite avec la vrai BDD). Juste le terme "Singleton" force l'utilisateur d'une classe à se mettre dans la tête qu'il n'y aura qu'une seule instance. Après pour l'accès globale c'est plus un effet de bord pratique qu'autre chose.


edit> En fait, j'ai refactoré plusieurs fois de manière massive des libs perso chez moi dans le but d'obtenir quelque chose sans singleton. J'en suis arrivé à la conclusion que seules les interfaces de l'environnement ayant un etat local (typiquement les systèmes de log, même boost::log a un singleton planqué) était le seul cas ou un pattern singleton avait un interet.
Ce que je fais du coup, pour être certain de limiter le singleton au strict nécessaire, c'est, comme beaucoup d'autre font, de designer la classe spécifique de manière non-singleton. Ensuite seulement à l'utilisation, quand je vois clairement que je tombe dans le souci de l'instance unique, j'utilise le pattern par CRTP (classique je pense - une fois qu'on a compris les pièges).

Au final je me retrouve rarement avec des singletons dans les bibliothèques, par contre souvent au moins un dans les applications "finales" ou clientes des bibliothèques. La raison c'est simplement la dépendance à une partie de l'environnement, ou simplement les logs. En fait pour les logs, j'ai essayer sans aucun singleton mais au final je me retrouve par en mettre un quelque part, pparcequ'il faut bien qu'il y ait quelque chose d'unique pour gérere les différents canaux de logs en cours, sans avoir a réouvrir des fichiers etc. On pourrait y aller via un système de statiques mais dans ce cas c'est chaud à gérer en multi-thread, entre autre.

[LittleWhite]

Pas si l'objet, comme dans mes cas d'utilisation, représente un unique système de l'environnement (avec un etat . Par exemple l'acquisition des entrées (clavier/souris/autre pour du jeu par exemple). Il y a un objet par materiel (donc plusieurs instances), mais il n'y a qu'un objet qui les détiens tous, les mes a jour etc.(donc une seule instance). Permettre plusieurs instances pour ce dernier objet serait simplement permettre que des érreurs alors qu'elles sont facile à eradiquer (en n'ayant qu'un seul objet).

Et encore, cela n'est pas totalement vrai, dans le cas d'un jeu avec de joueur sur un seul peripherique ... Il y aura bien deux objets sur un materiel. Et de plus, avec votre instance unique, il est difficile de differencier par la suite quel joueur aura fait l'action.