C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  [HS] Singleton, un anti-pattern ? Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ (French) View previous topic :: View next topic   Author Message Patrick Mézard Guest Posted: Sun Jul 17, 2005 9:11 am    Post subject: [HS] Singleton, un anti-pattern ? Bonjour, Suite à la dernière itération de la discussion récurrente sur DCL et les singletons, je me posais la question suivante : le "Singleton" est-il vraiment utile à quelque chose ? A chaque fois que j'ai vu ce truc apparaître comme par magie là où on ne l'attendait pas c'était pour une des raisons suivantes : 1- Ca permet d'avoir des variables globales sous couvert de respectabilité. Bah oui, c'est dans le légendaire _Design Patterns_, donc... 2- "C'est cool". C'est le seul motif de conception (encore merci wikipedia, <http://fr.wikipedia.org/wiki/Motif_de_conception>) que j'ai compris ou que j'arrive à utiliser alors je m'en sers. Sinon j'aurais lu l'autre bouquin pour rien. 3- "C'est cool et ça en jette de complexité". Y a un chapitre entier sur le single ultime dans _Modern C++ Design_. Tous les problèmes sont réglés une fois pour toute : durée de vie, interdépendance, multi-threading (ah tiens, du DCL !) et j'en passe. C'est tellement subtil, ça ne peut pas être inutile ? 4- Ca fait beau dans une doc ou sur un schéma de conception. 5- "J'étais pourtant certain qu'il n'y en aurait qu'un !" 6- Ca permet de corriger d'autres problèmes de conception. En définitive, existe-t-il des exemples justifiant l'emploi d'un Singleton ? N'est-il pas toujours possible de créer une instance lors d'une phase d'initialisation quelconque et de l'enregistrer auprès d'éventuels autres objets ? Comme toujours, la seule raison valide que je vois reste la [6] (une mauvaise conception préalable justifie tout et n'importe quoi), auquel cas le Singleton serait plus un motif de correction/réparation que de conception. Qu'en pensez-vous ? Patrick Mézard Back to top Loïc Joly Guest Posted: Sun Jul 17, 2005 10:05 am    Post subject: Re: [HS] Singleton, un anti-pattern ? Patrick Mézard a écrit : Quote: Bonjour, Suite à la dernière itération de la discussion récurrente sur DCL et les singletons, je me posais la question suivante : le "Singleton" est-il vraiment utile à quelque chose ? A chaque fois que j'ai vu ce truc apparaître comme par magie là où on ne l'attendait pas c'était pour une des raisons suivantes : 1- Ca permet d'avoir des variables globales sous couvert de respectabilité. Bah oui, c'est dans le légendaire _Design Patterns_, donc... Ca permet d'avoir aussi des variables globales qu'on peut utiliser depuis d'autres variables globales sans problème d'ordre d'initialisation. Quote: 2- "C'est cool". C'est le seul motif de conception (encore merci wikipedia, <http://fr.wikipedia.org/wiki/Motif_de_conception>) que j'ai compris ou que j'arrive à utiliser alors je m'en sers. Sinon j'aurais lu l'autre bouquin pour rien. C'est un peu le reproche (totalement immérité, je sais) que je fait à Design Pattern : A une époque, j'ai vu une mode des design patterns. Si je mets un design pattern (singleton au hasard) dans mon code, c'est forcément que mon code est bon. Quote: En définitive, existe-t-il des exemples justifiant l'emploi d'un Singleton ? Probablement, mais probablement pas souvent. Même les exemples classiques me semblent finalement mauvais. Par exemple : Un singleton peut représenter une chose forcément unique, comme l'écran d'un PC... Si je devais faire un cours d'introduction rapide sur quelques design patterns, le singleton n'y figurerais certainement pas. -- Loïc Back to top Arnaud Debaene Guest Posted: Sun Jul 17, 2005 5:06 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? Patrick Mézard wrote: Quote: Bonjour, Suite à la dernière itération de la discussion récurrente sur DCL et les singletons, je me posais la question suivante : le "Singleton" est-il vraiment utile à quelque chose ? A chaque fois que j'ai vu ce truc apparaître comme par magie là où on ne l'attendait pas c'était pour une des raisons suivantes : 1- Ca permet d'avoir des variables globales sous couvert de respectabilité. Bah oui, c'est dans le légendaire _Design Patterns_, donc... 2- "C'est cool". C'est le seul motif de conception (encore merci wikipedia, <http://fr.wikipedia.org/wiki/Motif_de_conception>) que j'ai compris ou que j'arrive à utiliser alors je m'en sers. Sinon j'aurais lu l'autre bouquin pour rien. 3- "C'est cool et ça en jette de complexité". Y a un chapitre entier sur le single ultime dans _Modern C++ Design_. Tous les problèmes sont réglés une fois pour toute : durée de vie, interdépendance, multi-threading (ah tiens, du DCL !) et j'en passe. C'est tellement subtil, ça ne peut pas être inutile ? 4- Ca fait beau dans une doc ou sur un schéma de conception. 5- "J'étais pourtant certain qu'il n'y en aurait qu'un !" 6- Ca permet de corriger d'autres problèmes de conception. En définitive, existe-t-il des exemples justifiant l'emploi d'un Singleton ? N'est-il pas toujours possible de créer une instance lors d'une phase d'initialisation quelconque et de l'enregistrer auprès d'éventuels autres objets ? Tu oublies le cas le + simple : quand je dois modéliser un objet qui ne peut exister que de amnière unique dans un système (c'est le but après tout). Au fait, tu utilises certainement des singletons régulièrement : cin, cout et cerr par exemple. Arnaud Back to top Patrick Mézard Guest Posted: Sun Jul 17, 2005 5:17 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? Loïc Joly wrote: Quote: Patrick Mézard a écrit : Bonjour, Suite à la dernière itération de la discussion récurrente sur DCL et les singletons, je me posais la question suivante : le "Singleton" est-il vraiment utile à quelque chose ? A chaque fois que j'ai vu ce truc apparaître comme par magie là où on ne l'attendait pas c'était pour une des raisons suivantes : 1- Ca permet d'avoir des variables globales sous couvert de respectabilité. Bah oui, c'est dans le légendaire _Design Patterns_, donc... Ca permet d'avoir aussi des variables globales qu'on peut utiliser depuis d'autres variables globales sans problème d'ordre d'initialisation. Du coup, on arrive à une deuxième question, la nécessité d'avoir des variables globales non-const. Mais ça va faire un peu trop pour aujourd'hui . -- Patrick Back to top Stan Guest Posted: Sun Jul 17, 2005 5:23 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? "Patrick Mézard" <pmezard (AT) gmail (DOT) com> a écrit dans le message de news: 42da20a5$0$22286$8fcfb975 (AT) news (DOT) wanadoo.fr... Quote: Bonjour, Suite à la dernière itération de la discussion récurrente sur DCL et les singletons, je me posais la question suivante : le "Singleton" est-il vraiment utile à quelque chose ? A chaque fois que j'ai vu ce truc apparaître comme par magie là où on ne l'attendait pas c'était pour une des raisons suivantes : [...] Comme toujours, la seule raison valide que je vois reste la [6] (une mauvaise conception préalable justifie tout et n'importe quoi), auquel cas le Singleton serait plus un motif de correction/réparation que de conception. Qu'en pensez-vous ? Que si on a des doutes sur l'utilité de qq chose, c'est qu'on en a pas réellement besoin... -- -Stan Back to top Jean-Marc Bourguet Guest Posted: Sun Jul 17, 2005 6:26 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? Patrick Mézard <pmezard (AT) gmail (DOT) com> writes: Quote: Comme toujours, la seule raison valide que je vois reste la [6] (une mauvaise conception préalable justifie tout et n'importe quoi), auquel cas le Singleton serait plus un motif de correction/réparation que de conception. Qu'en pensez-vous ? Je me demande si en fait tu n'es pas en train de t'attaquer à toute forme d'état persistant entre appels, que cet état prenne la forme de variable globale normale, de singleton ou de variable statique dans des fonctions. On peut naturellement toujours s'en passer: il suffit de rendre cet état explicite et de se le faire passer comme paramètre. On peut même prétendre sans être trop de mauvaise fois que c'est en prévision pour le moment où cet état ne pourra plus être partagé. Mais je ne pense pas pour autant que le faire soit toujours la meilleure solution -- même sans erreurs de conception par ailleurs. On arrive assez naturellement à des singletons quand on conçoit son système comme composé de composants interagissant entre eux. Certains peuvent être intrinsèquement unique et connu de quasiment tout le monde (par exemple le composant qui gère l'affichage). Ne pas en faire un état global poserait des problèmes pratiques (comment assurer l'initialisation de ces deux composants qui se connaisse l'un l'autre, ou bien le passe partout, ou bien on le stocke à des endroits multiples -- et je t'assure qu'en pratique tous le monde "saura" que tous les moyens d'y accéder sont équivalents, donc quasiment rien ne sera facilité s'il faut rendre l'état non unique; j'ai déjà vécu des cas où un mécanisme d'une généralité excessive avait été mis en place et être en pratique inutilisable le moment venu parce que, primo, tout le monde "savait" qu'il n'était pas utilisé et avait agit avec cette hypothèse et, deuxio, la généralisation qui était effectivement utile n'avait pas été prévue). Un exemple extrême où rendre l'état visible par les appelants me semble absolument exclu: une fonction dont le résultat ne dépend que des paramètres, mais coûteuse à calculer. Comme elle est souvent appelée avec les mêmes arguments, on décide de cacher le résultat. A+ -- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org Back to top Patrick Mézard Guest Posted: Sun Jul 17, 2005 6:33 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? Stan wrote: Quote: "Patrick Mézard" <pmezard (AT) gmail (DOT) com> a écrit dans le message de news: 42da20a5$0$22286$8fcfb975 (AT) news (DOT) wanadoo.fr... Bonjour, Suite à la dernière itération de la discussion récurrente sur DCL et les singletons, je me posais la question suivante : le "Singleton" est-il vraiment utile à quelque chose ? Qu'en pensez-vous ? Que si on a des doutes sur l'utilité de qq chose, c'est qu'on en a pas réellement besoin... Ou qu'on a fait mieux ou autrement depuis. -- Patrick Back to top Fabien LE LEZ Guest Posted: Sun Jul 17, 2005 7:55 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? On Sun, 17 Jul 2005 19:17:07 +0200, Patrick Mézard <pmezard (AT) gmail (DOT) com>: Quote: Du coup, on arrive à une deuxième question, la nécessité d'avoir des variables globales non-const. On peut même aller plus loin, et remettre en question la nécessité d'avoir des langages de programmation ;-p Back to top Patrick Mézard Guest Posted: Sun Jul 17, 2005 8:42 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? Jean-Marc Bourguet wrote: Quote: Je me demande si en fait tu n'es pas en train de t'attaquer à toute forme d'état persistant entre appels, que cet état prenne la forme de variable globale normale, de singleton ou de variable statique dans des fonctions. C'est presque ça. En fait, ce qui m'ennuie le plus c'est la difficulté à cloisonner l'usage de ces objets (variables globales ou singleton puisque c'est quasiment la même chose). Cela complique beaucoup : 1- La gestion de la durée de vie des instances. Je préfère créer et détruire ces objets à la main plutôt que compter sur des artifices parfois complexes pour gèrer ça tout seul. 2- Le réusinage. Il est difficile de savoir qui utilise exactement ces objets. Les couplages deviennent forts et peu apparents. 3- L'utilisation dans des environnements concurrents. Les techniques d'accès synchronisés dans des milieux multithreads ou autres dépendent énormément du type des accès. Il suffit de voir l'énergie dépensée autour de DCL pour mesurer le coût d'accès totalement libres à un malheureux pointeur. Quote: On peut naturellement toujours s'en passer: il suffit de rendre cet état explicite et de se le faire passer comme paramètre. On peut même prétendre sans être trop de mauvaise fois que c'est en prévision pour le moment où cet état ne pourra plus être partagé. Mais je ne pense pas pour autant que le faire soit toujours la meilleure solution -- même sans erreurs de conception par ailleurs. On arrive assez naturellement à des singletons quand on conçoit son système comme composé de composants interagissant entre eux. Certains peuvent être intrinsèquement unique et connu de quasiment tout le monde (par exemple le composant qui gère l'affichage). Ne pas en faire un état global poserait des problèmes pratiques (comment assurer l'initialisation de ces deux composants qui se connaisse l'un l'autre, ou bien le passe partout, ou bien on le stocke à des endroits multiples -- et je t'assure qu'en pratique tous le monde "saura" que tous les moyens d'y accéder sont équivalents, donc quasiment rien ne sera facilité s'il faut rendre l'état non unique; j'ai déjà vécu des cas où un mécanisme d'une généralité excessive avait été mis en place et être en pratique inutilisable le moment venu parce que, primo, tout le monde "savait" qu'il n'était pas utilisé et avait agit avec cette hypothèse et, deuxio, la généralisation qui était effectivement utile n'avait pas été prévue). C'est donc un compromis entre l'isolation des composants et leur simplicité d'utilisation. C'est drôle parce que j'ai toujours fait l'effort de cloisonner les composants alors que je n'ai travaillé que sur des projets de petite taille. Et j'imaginais que ce besoin de cloisonnement se renforçait avec la taille de la base de code. A chaque fois que j'ai reusiné du code en enlevant des structures du type singleton j'ai eu l'impression d'y gagner en clarté et de mettre en évidence d'autres problèmes de conception plus profonds. Travailler avec des instances permet peut-être de mieux documenter les interactions entre les composants, et quelque part de clarifier le design. Disons qu'à chaque fois qu'on enregistre ou libère une référence, les questions de durée de vie ressurgissent, ce qui arrive moins si on manipule des objets statiques pour lesquels on n'est pas vraiment responsable. Tout ça est très subjectif, peut-être que je passe un temps fou à échanger des pointeurs entre mes composants. Finalement, c'est la version API du singleton qui m'ennuie le plus. J'admets bien l'existence d'objets uniques au sein d'un système, mais il doivent rester peu visibles. Quote: Un exemple extrême où rendre l'état visible par les appelants me semble absolument exclu: une fonction dont le résultat ne dépend que des paramètres, mais coûteuse à calculer. Comme elle est souvent appelée avec les mêmes arguments, on décide de cacher le résultat. Je ne comprends pas ton exemple. -- Patrick Back to top Loïc Joly Guest Posted: Sun Jul 17, 2005 10:04 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? Arnaud Debaene a écrit : Quote: Tu oublies le cas le + simple : quand je dois modéliser un objet qui ne peut exister que de amnière unique dans un système (c'est le but après tout). Au fait, tu utilises certainement des singletons régulièrement : cin, cout et cerr par exemple. Depuis quand ce sont des singletons ? Quote: 27.3 Standard iostream objects Header <iostream> synopsis namespace std { extern istream cin; extern ostream cout; extern ostream cerr; extern ostream clog; extern wistream wcin; extern wostream wcout; extern wostream wcerr; extern wostream wclog; } Rien n'empêche l'utilisateur de créer d'autres objets de type istream, ostream... -- Loïc Back to top Patrick Mézard Guest Posted: Sun Jul 17, 2005 10:47 pm    Post subject: Re: [HS] Singleton, un anti-pattern ? Arnaud Debaene wrote: Quote: Patrick Mézard wrote: Bonjour, Suite à la dernière itération de la discussion récurrente sur DCL et les singletons, je me posais la question suivante : le "Singleton" est-il vraiment utile à quelque chose ? Tu oublies le cas le + simple : quand je dois modéliser un objet qui ne peut exister que de amnière unique dans un système (c'est le but après tout). Au fait, tu utilises certainement des singletons régulièrement : cin, cout et cerr par exemple. Comme le dit Loïc, ce ne sont pas à proprement parler des singletons mais des variables globales (et il a parfois des problèmes d'initialisation si on essaye d'y accèder avant le main()). Ceci dit ça reste un très bon exemple parce qu'il met en valeur les choses suivantes : 1- Ce sont des variables globales qui implémentent des interfaces, en l'occurence std::istream ou std::ostream, et on les utilise souvent de façon polymorphique. C'est quand même rare de parler directement à std::cout. En général on le sélectionne lors d'une phase de configuration et on le passe à des fonctions prenant du std::ostream. Ce genre d'usage se rapproche du cas "on crée les instances et on les distribue aux objets concernés". A la différence d'un motif classique de singleton, le type est clairement dissocié des instances. 2- Il arrive aussi d'utiliser std::cout de n'importe où, particulièrement pour faire des "traces" (des enregistrements ?). Ce genre d'utilisation me pose un vrai problème. En pratique, je ne veux pas que l'existence des enregistreurs impacte le design de l'application ou de la bibliothèque. Comme ce sont *a priori* des outils de développement et pas des fonctionnalités, je ne veux pas passer ces instances dans les fonctions, je dois accèder à des objets globaux. De fait, je ne me souviens pas avoir vu de bibliothèque de logging sans singleton/globale. Mais Loïc a peut-être un autre avis sur le sujet ? Conclusion, avec les contraintes de (2) je ne sais pas me passer de singletons ou équivalents. Maintenant on peut encore discuter du : "Comme ce sont *a priori* des outils de développement et pas des fonctionnalités, je ne veux pas passer ces instances dans les fonctions". -- Patrick Back to top Loïc Joly Guest Posted: Mon Jul 18, 2005 12:15 am    Post subject: Re: [HS] Singleton, un anti-pattern ? Patrick Mézard a écrit : Quote: 2- Il arrive aussi d'utiliser std::cout de n'importe où, particulièrement pour faire des "traces" (des enregistrements ?). Ce genre d'utilisation me pose un vrai problème. En pratique, je ne veux pas que l'existence des enregistreurs impacte le design de l'application ou de la bibliothèque. Comme ce sont *a priori* des outils de développement et pas des fonctionnalités, je ne veux pas passer ces instances dans les fonctions, je dois accèder à des objets globaux. De fait, je ne me souviens pas avoir vu de bibliothèque de logging sans singleton/globale. Mais Loïc a peut-être un autre avis sur le sujet ? Disons que je n'ai rien contre l'utilisation de variables globales pour ce genre de situation. Le fait d'utiliser un singleton me semblerait par contre ajouter une contrainte supplémentaire et enlever des fonctionnalités à l'utilisateur. Par exemple, pour le logging, si l'objet de log est un singleton, il est unique. Point. Si c'est juste une variable globale, même si le concepteur du log ne l'a pas prévu, rien n'empêche l'utilisateur d'avoir 2 log, par exemple un mode succint et un mode détaillé, dans deux fichiers différents avec deux objets différents. J'ai l'impression que souvent les singletons représentent une limitation artificielle et arbitraire. Dans beaucoup de cas, cette limitation n'est pas gênante, mais quand elle le devient... Mettre du log en singleton, c'est pour moi un peu comme si on décidait qu'un PC n'aurait jamais plus de 640ko de mémoire. -- Loïc Back to top kanze@gabi-soft.fr Guest Posted: Mon Jul 18, 2005 9:38 am    Post subject: Re: Singleton, un anti-pattern ? Patrick Mézard wrote: [...] Quote: C'est donc un compromis entre l'isolation des composants et leur simplicité d'utilisation. C'est drôle parce que j'ai toujours fait l'effort de cloisonner les composants alors que je n'ai travaillé que sur des projets de petite taille. Et j'imaginais que ce besoin de cloisonnement se renforçait avec la taille de la base de code. A chaque fois que j'ai reusiné du code en enlevant des structures du type singleton j'ai eu l'impression d'y gagner en clarté et de mettre en évidence d'autres problèmes de conception plus profonds. Le problème, c'est que souvent, il y a des spécifications dans le cahier de charge qui ont un aspect universel. Donc, par exemple, il est fréquent de rétrouver une exigeance que le log soit configurable, de façon à ce qu'on peut envoyer les erreurs les plus sévère par email, d'autres au syslog, et que la plupart n'apparaissent que lors des mises à point, quand il vont dans un fichier classique. On peut, effectivement, créer un objet de log dans le main, qu'on passe par paramètre partout. Mais ça introduit la possibilité que quelqu'un en créer deux, par erreur ; dans ce cas-là, le singleton est un moyen d'assurer que l'objet soit unique. À cet égard, il ne faut pas confondre le concepte de singleton avec son implémentation dans un langage donné. Un singleton, c'est un objet dont il ne peut exister qu'une seule instance. Par définition, et non par hazard -- un autre poster a cité comme exemple l'écran d'un PC, alors que la plupart des PC ici sont équipés de deux écrans. Il y a réelement très peu d'utilisations d'un singleton : les log et les configurations sont les deux classiques. Encore que ça dépend de l'application ; si le cahier de charges exige un traitement unique, ils doivent probablement être des singletons (au sens de la conception), sinon, ils ne doivent certainement pas l'être. Quote: Travailler avec des instances permet peut-être de mieux documenter les interactions entre les composants, et quelque part de clarifier le design. Oui et non. Si le cahier de charges dit que tous les composants doivent se comporter de la même façon vis-à-vis de, disons, le logging, je le vois comme une clarification de *ne pas* passer un paramètre de type d'objet log -- passer le paramètre suggère déjà qu'il puisse en avoir plusieurs. Quote: Disons qu'à chaque fois qu'on enregistre ou libère une référence, les questions de durée de vie ressurgissent, ce qui arrive moins si on manipule des objets statiques pour lesquels on n'est pas vraiment responsable. Tout ça est très subjectif, peut-être que je passe un temps fou à échanger des pointeurs entre mes composants. Je repette : ce n'est pas une question de performance, mais de lisibilité. Passer systèmatiquement trente-six paramètres qui sont toujours les mêmes, d'après le cahier de charges, ajoute au bruit, et le rend plus difficile à voir les paramètres qui varient réelement. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Back to top kanze@gabi-soft.fr Guest Posted: Mon Jul 18, 2005 9:49 am    Post subject: Re: Singleton, un anti-pattern ? Patrick Mézard wrote: Quote: Suite à la dernière itération de la discussion récurrente sur DCL et les singletons, je me posais la question suivante : le "Singleton" est-il vraiment utile à quelque chose ? A chaque fois que j'ai vu ce truc apparaître comme par magie là où on ne l'attendait pas c'était pour une des raisons suivantes : 1- Ca permet d'avoir des variables globales sous couvert de respectabilité. Bah oui, c'est dans le légendaire _Design Patterns_, donc... Ça permet, effectivement, d'avoir des variables globales. Plus important, à mon avis, ça permet à s'assurer que tout le monde se sert de ces variables globales, et non de leur propre instance. Ce qui fait le singleton, c'est qu'il ne peut y avoir qu'une seule instance. Quote: 2- "C'est cool". C'est le seul motif de conception (encore merci wikipedia, http://fr.wikipedia.org/wiki/Motif_de_conception>) que j'ai compris ou que j'arrive à utiliser alors je m'en sers. Sinon j'aurais lu l'autre bouquin pour rien. Bizarre, bizarre. Parce que parmi les motifs ce conception, ça en est un qui me sert le moins. Quote: 3- "C'est cool et ça en jette de complexité". Y a un chapitre entier sur le single ultime dans _Modern C++ Design_. Tous les problèmes sont réglés une fois pour toute : durée de vie, interdépendance, multi-threading (ah tiens, du DCL !) et j'en passe. C'est tellement subtil, ça ne peut pas être inutile ? J'avoue que je ne me suis jamais senti le besoin de quelque chose de compliqué pour un Singleton. L'intérêt, justement, c'est de le garder simple. Quote: 4- Ca fait beau dans une doc ou sur un schéma de conception. Dans quel sens. Ça fait beau s'il contribue à la réalisation du cahier de charges. Sinon... Quote: 5- "J'étais pourtant certain qu'il n'y en aurait qu'un !" Si le cahier de charges exige une centralisation de certaines fonctionalités... C'est souvent le cas du logging, par exemple. C'est que tu ne veux pas prendre la risque qu'il puisse en avoir deux -- tu veux être 100% certain que tout le monde utilise l'unique instance. Comme ça, quand on ajoute l'envoie de certains messages à Tivoli au cahier de charges, tu es sûr qu'ayant ajouter la configuration à la seule instance, tous les composants sont affectés. Quote: 6- Ca permet de corriger d'autres problèmes de conception. Ça, c'est plutôt la rôle des fonctions virtuelles et l'héritage en spaghetti:-). Quand on trouve un problème quelconque, on corrige la véritable erreur. S'il s'agit d'une erreur dans la conception, on modifie la conception, et on répercute les changes vers le bas. Sinon, au bout de six moins, le programme n'est plus maintenable. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Back to top Geoffrey Guest Posted: Mon Jul 18, 2005 9:53 am    Post subject: Re: [HS] Singleton, un anti-pattern ? "Loïc Joly" <loic.actarus.joly (AT) wanadoo (DOT) fr> a écrit dans le message de news: 42daf3e2$0$2514$a3f2974a (AT) nnrp1 (DOT) numericable.fr... Quote: Patrick Mézard a écrit : 2- Il arrive aussi d'utiliser std::cout de n'importe où, particulièrement pour faire des "traces" (des enregistrements ?). Ce genre d'utilisation me pose un vrai problème. En pratique, je ne veux pas que l'existence des enregistreurs impacte le design de l'application ou de la bibliothèque. Comme ce sont *a priori* des outils de développement et pas des fonctionnalités, je ne veux pas passer ces instances dans les fonctions, je dois accèder à des objets globaux. De fait, je ne me souviens pas avoir vu de bibliothèque de logging sans singleton/globale. Mais Loïc a peut-être un autre avis sur le sujet ? Disons que je n'ai rien contre l'utilisation de variables globales pour ce genre de situation. Le fait d'utiliser un singleton me semblerait par contre ajouter une contrainte supplémentaire et enlever des fonctionnalités à l'utilisateur. Par exemple, pour le logging, si l'objet de log est un singleton, il est unique. Point. Si c'est juste une variable globale, même si le concepteur du log ne l'a pas prévu, rien n'empêche l'utilisateur d'avoir 2 log, par exemple un mode succint et un mode détaillé, dans deux fichiers différents avec deux objets différents. Tu peux avoir aussi un gestionnaire de log en Singleton qui gere plusieurs maniere de logger une Infos ... tu ne fera qu'un appel, et tu auras tes n logs. Quote: J'ai l'impression que souvent les singletons représentent une limitation artificielle et arbitraire. Dans beaucoup de cas, cette limitation n'est pas gênante, mais quand elle le devient... Mettre du log en singleton, c'est pour moi un peu comme si on décidait qu'un PC n'aurait jamais plus de 640ko de mémoire. D'un point de vue de lisibilité du code, le Singleton m'apparait ( ca n'engage que moi ) ) plus simple qu'un objet static global ( declaré ou ? Initialisé a quel endroit ? ). Je pense plus que la limitation provient de ton objet Singleton et non du Singleton en lui même ... Quote: -- Loïc Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (French) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.