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.
En fait, le livre Design Patterns n'a probablement changé rien dans ta façon d'écrire du code.
Toi, peut-être pas. Mais il n'empêche qu'il donne des solutions auxquelles on n'aurait pas forcément pensé, ou pas pensé du premier coup.
Oui et non. Dans mon cas, je n'ai pas changé le domaine d'application après avoir lu le livre. Et ayant travaillé depuis un certain temps dans le domaine, j'avais déjà rencontré la plupart des problèmes. Et donc, j'en connaissais la solution. J'étais même très conscient d'(re-)utliser les mêmes solutions, d'une façon assez systèmatique.
Ce qu'il me manquait, et ce que Design Patterns m'a apporté, c'était la façon d'en parler, et de communiquer cette information aux gens qui lisaient mon code. Avant le livre, chaque programmeur compétant finissait avec l'expérience par avoir sa propre collection de modèles de conception, dont il s'en servait regulièrement. Mais c'était vraiment chacun pour soi -- personne ne reconnaissait mes modèles, et je ne reconnaissais pas les modèles des autres. (À moins d'avoir lu beaucoup du code de l'autre, en tout cas.) Et chaque fois que je réutilisais un de mes propre modèles, il fallait tout rédocumenter en détail, comme si je créais quelque chose de neuf.
À ce titre, je considère que, pour moi, il a changé ma façon d'écrire du code. Les visiteurs, les stratégies, les factories ou les décorateurs sont devenus des architectures de conceptions bien identifiées avant même d'avoir été en présence des problèmes qu'ils résolvent, ou avant d'en avoir trouvé une solution générique, réutilisable et identifiable.
En revanche, il a dû changer beaucoup dans ta façon de le documenter. Et ceux qui te suivre en sauront gré.
Ça, c'est clair.
Arnaud (qui n'avait pas inventé les design patterns avant d'avoir lu le bouquin)
Peut-être pas conscieusement. Mais je parie que quand tu rencontrais un problème que tu avais déjà vu, tu en basais ta solution sur la solution précédante. (À moins que tu sois réelement été débuttant à l'époque, et que tu n'avais pas encore résolu de vraies problèmes.)
-- 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
Arnaud Meurgues wrote:
kanze@gabi-soft.fr wrote:
En fait, le livre Design Patterns n'a probablement changé
rien dans ta façon d'écrire du code.
Toi, peut-être pas. Mais il n'empêche qu'il donne des
solutions auxquelles on n'aurait pas forcément pensé, ou pas
pensé du premier coup.
Oui et non. Dans mon cas, je n'ai pas changé le domaine
d'application après avoir lu le livre. Et ayant travaillé depuis
un certain temps dans le domaine, j'avais déjà rencontré la
plupart des problèmes. Et donc, j'en connaissais la solution.
J'étais même très conscient d'(re-)utliser les mêmes solutions,
d'une façon assez systèmatique.
Ce qu'il me manquait, et ce que Design Patterns m'a apporté,
c'était la façon d'en parler, et de communiquer cette
information aux gens qui lisaient mon code. Avant le livre,
chaque programmeur compétant finissait avec l'expérience par
avoir sa propre collection de modèles de conception, dont il
s'en servait regulièrement. Mais c'était vraiment chacun pour
soi -- personne ne reconnaissait mes modèles, et je ne
reconnaissais pas les modèles des autres. (À moins d'avoir lu
beaucoup du code de l'autre, en tout cas.) Et chaque fois que
je réutilisais un de mes propre modèles, il fallait tout
rédocumenter en détail, comme si je créais quelque chose de
neuf.
À ce titre, je considère que, pour moi, il a changé ma façon
d'écrire du code. Les visiteurs, les stratégies, les factories
ou les décorateurs sont devenus des architectures de
conceptions bien identifiées avant même d'avoir été en
présence des problèmes qu'ils résolvent, ou avant d'en avoir
trouvé une solution générique, réutilisable et identifiable.
En revanche, il a dû changer beaucoup dans ta façon de le
documenter. Et ceux qui te suivre en sauront gré.
Ça, c'est clair.
Arnaud (qui n'avait pas inventé les design patterns avant
d'avoir lu le bouquin)
Peut-être pas conscieusement. Mais je parie que quand tu
rencontrais un problème que tu avais déjà vu, tu en basais ta
solution sur la solution précédante. (À moins que tu sois
réelement été débuttant à l'époque, et que tu n'avais pas encore
résolu de vraies problèmes.)
--
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
En fait, le livre Design Patterns n'a probablement changé rien dans ta façon d'écrire du code.
Toi, peut-être pas. Mais il n'empêche qu'il donne des solutions auxquelles on n'aurait pas forcément pensé, ou pas pensé du premier coup.
Oui et non. Dans mon cas, je n'ai pas changé le domaine d'application après avoir lu le livre. Et ayant travaillé depuis un certain temps dans le domaine, j'avais déjà rencontré la plupart des problèmes. Et donc, j'en connaissais la solution. J'étais même très conscient d'(re-)utliser les mêmes solutions, d'une façon assez systèmatique.
Ce qu'il me manquait, et ce que Design Patterns m'a apporté, c'était la façon d'en parler, et de communiquer cette information aux gens qui lisaient mon code. Avant le livre, chaque programmeur compétant finissait avec l'expérience par avoir sa propre collection de modèles de conception, dont il s'en servait regulièrement. Mais c'était vraiment chacun pour soi -- personne ne reconnaissait mes modèles, et je ne reconnaissais pas les modèles des autres. (À moins d'avoir lu beaucoup du code de l'autre, en tout cas.) Et chaque fois que je réutilisais un de mes propre modèles, il fallait tout rédocumenter en détail, comme si je créais quelque chose de neuf.
À ce titre, je considère que, pour moi, il a changé ma façon d'écrire du code. Les visiteurs, les stratégies, les factories ou les décorateurs sont devenus des architectures de conceptions bien identifiées avant même d'avoir été en présence des problèmes qu'ils résolvent, ou avant d'en avoir trouvé une solution générique, réutilisable et identifiable.
En revanche, il a dû changer beaucoup dans ta façon de le documenter. Et ceux qui te suivre en sauront gré.
Ça, c'est clair.
Arnaud (qui n'avait pas inventé les design patterns avant d'avoir lu le bouquin)
Peut-être pas conscieusement. Mais je parie que quand tu rencontrais un problème que tu avais déjà vu, tu en basais ta solution sur la solution précédante. (À moins que tu sois réelement été débuttant à l'époque, et que tu n'avais pas encore résolu de vraies problèmes.)
-- 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
Arnaud Meurgues
wrote:
(À moins que tu sois réelement été débuttant à l'époque, et que tu n'avais pas encore résolu de vraies problèmes.)
Oui. Quand je l'ai lu, je n'avais pas commencé à travailler (en fait, je crois que j'étais au support, ce qui ne nécessite aucune conception).
Arnaud
kanze@gabi-soft.fr wrote:
(À moins que tu sois
réelement été débuttant à l'époque, et que tu n'avais pas encore
résolu de vraies problèmes.)
Oui. Quand je l'ai lu, je n'avais pas commencé à travailler (en fait, je
crois que j'étais au support, ce qui ne nécessite aucune conception).
