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 :-) ?
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 :-) ?
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 :-) ?
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.
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.
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.
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.
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.
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.
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
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
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
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.
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.
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.
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.
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.
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.
Loïc Joly wrote:
[...]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.
Tu n'inventes pas la roue à chaque ligne de code. Que tu as
entendu parler des Design Patterns ou non, si tu te trouves
devant un problème que tu as déjà résolu dans la passée, tu
utilises la solution qui a marché dans la passée.
En fait, le livre Design Patterns n'a probablement changé rien
dans ta façon d'écrire du code. En revanche, il a dû changer
beaucoup dans ta façon de le documenter. Et ceux qui te suivre
en sauront gré.
Loïc Joly wrote:
[...]
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.
Tu n'inventes pas la roue à chaque ligne de code. Que tu as
entendu parler des Design Patterns ou non, si tu te trouves
devant un problème que tu as déjà résolu dans la passée, tu
utilises la solution qui a marché dans la passée.
En fait, le livre Design Patterns n'a probablement changé rien
dans ta façon d'écrire du code. En revanche, il a dû changer
beaucoup dans ta façon de le documenter. Et ceux qui te suivre
en sauront gré.
Loïc Joly wrote:
[...]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.
Tu n'inventes pas la roue à chaque ligne de code. Que tu as
entendu parler des Design Patterns ou non, si tu te trouves
devant un problème que tu as déjà résolu dans la passée, tu
utilises la solution qui a marché dans la passée.
En fait, le livre Design Patterns n'a probablement changé rien
dans ta façon d'écrire du code. En revanche, il a dû changer
beaucoup dans ta façon de le documenter. Et ceux qui te suivre
en sauront gré.
Je lui demande pourquoi il a décidé que A serait un singleton, et sa
réponse n'était pas : Parce-que pour telle ou telle raison, il faut qu'il
n'y en ait qu'une seul instancié, et donc j'ai appliqué le pattern du
singleton. La réponse était du style : Parce que singleton est un design
pattern, et donc mon code est forcément bon.
J'ai vu cette dérive malsaine pour différents patterns et par différentes
personnes.
Je lui demande pourquoi il a décidé que A serait un singleton, et sa
réponse n'était pas : Parce-que pour telle ou telle raison, il faut qu'il
n'y en ait qu'une seul instancié, et donc j'ai appliqué le pattern du
singleton. La réponse était du style : Parce que singleton est un design
pattern, et donc mon code est forcément bon.
J'ai vu cette dérive malsaine pour différents patterns et par différentes
personnes.
Je lui demande pourquoi il a décidé que A serait un singleton, et sa
réponse n'était pas : Parce-que pour telle ou telle raison, il faut qu'il
n'y en ait qu'une seul instancié, et donc j'ai appliqué le pattern du
singleton. La réponse était du style : Parce que singleton est un design
pattern, et donc mon code est forcément bon.
J'ai vu cette dérive malsaine pour différents patterns et par différentes
personnes.
En fait, le livre Design Patterns n'a probablement changé rien
dans ta façon d'écrire du code.
En revanche, il a dû changer
beaucoup dans ta façon de le documenter. Et ceux qui te suivre
en sauront gré.
En fait, le livre Design Patterns n'a probablement changé rien
dans ta façon d'écrire du code.
En revanche, il a dû changer
beaucoup dans ta façon de le documenter. Et ceux qui te suivre
en sauront gré.
En fait, le livre Design Patterns n'a probablement changé rien
dans ta façon d'écrire du code.
En revanche, il a dû changer
beaucoup dans ta façon de le documenter. Et ceux qui te suivre
en sauront gré.
