Bonjour,
Je viens de terminer un article concernant le design pattern Singleton. Il est sensé être le premier d'une longue (si ça intéresse du monde) et intéressante (j'espère !) série d'articles visant à expliquer à ceux qui connaissent déjà les bases du langage des concepts sympatiques pouvant aider à améliorer les performances ou la praticité du code.
Désireux de fournir une présentation impeccable, j'ai rédigé tout ça en LaTeX, et le document est distribué avec ses codes exemples sous forme d'une archive contenant les sources (code + document), avec une version postscript reay-to-print.
Actuellement, tout ça n'a pas vraiment de license, et je me demande si une license Creative Common serait appropriée.
Donc pour ceux que ça intéresse, je suis ouvert à tout critique objective qui m'aidera à m'améliorer, tant au niveau du fond que de la forme.
Tant que j'y suis, joyeux Noël à tous !
http://darkmaster.sp.free.fr/articles/article_01.tar.bz2
# une suggestion
Posté par fabien . Évalué à 5.
comme ca il suffit de la bookmarquer pour venir voir les articles suivants
de ta longue serie...
[^] # Une autre suggestion
Posté par Ph Husson (site web personnel) . Évalué à 2.
2.Ca serait possible d'avoir un lien directe?
Parce que les sources j'aime bien mais bon etre obligé de prendre tt le lot bof
3.Dans le readme tu dis qu'il faut make mais sans makefile ca sert à qqc? :)
[^] # Re: Une autre suggestion
Posté par Anonyme . Évalué à 5.
1/ make pdf te sort le pdf tout de suite, mais ça suppose que tu ais LaTeX et dvipdf. En fait je n'inclus pas de pdf directement tout simplement car dvipdf me sort un pdf assez dégeulasse, avec des fonts toutes bizards. Ne me demande pas pourquoi... Pour le postscript, j'utilise gv qui affiche également le pdf.
2/ http://darkmaster.sp.free.fr/articles/article_01.ps
http://darkmaster.sp.free.fr/articles/article_01.pdf
Mais ce n'est pas très utile, sans les codes exemples.
3/ Voir plus haut :)
Pour le site, c'est prévu quand j'aurais 3 ou 4 articles.
[^] # Re: Une autre suggestion
Posté par Sebastien (site web personnel) . Évalué à 5.
- jeter et brûler dvipdf.
- utiliser pdflatex
- utiliser les packages fournissant de jolies fontes (times, pslatex)
seb.
[^] # Re: une suggestion
Posté par Fabien Engels . Évalué à 4.
# bonne idée
Posté par schyzomarijks . Évalué à 1.
quelques petites questions,
pourquoi la méthode get n'appelle pas init directement dans le cas ou on ne veut pas nécessairement gérer la durée de vie de l'objet ?
par exemple
template<class T>
T* Singleton<T>::get() {
if (instance == NULL) {
this->init();
}
return instance ;
}
il y a-t il un moyen élégant de passer des paramètres au constructeur de T ?
après le "delete instance ;", ne serait-il pas plus judicieux de mettre "instance=NULL;" ???
une version thread safe pourrait être sympa à développer aussi :-)
sinon, une sortie en html ou pdf est une bonne idée.
[^] # Re: bonne idée
Posté par Anonyme . Évalué à 3.
La méthode templatisée utilise la gestion du cycle de vie, mais comme tu viens de le montrer, il est très simple de d'automatiser l'initialisation. Enfin je ne sais pas pour toi, mais sur les gros projets, moi j'aime bien regrouper l'initialisation de managers à un même endroit, et les gérer comme qu'il faut. Dans ton cas, si je rajoute du code utilisant get() ailleurs, je peux ne pas remarquer que l'initialisation a été appelée à un autre moment. Cela peut poser problème (testé par moi-même :p)
Mhh... Là cela devient un peu violent, je n'ai jamais essayé ;
Une idée, juste comme ça:
- Définir une classe générique ctor_param servant à contenir divers paramètres.
- Dériver ctor_param pour tes différents types de classes 'singletonisées'.
- Passer un second paramètre template à Singleton, et un paramètre de type ctor_param* à init().
- Fais un dynamic_cast<second_parametre_de_template*>(parametre_de_init).
Et voilà, tu as tout comme tu veux.
Ne me demande pas si c'est optimal, mais ça me parait propre et efficace.
De toute manière, je n'ai jamais eu besoin de le faire.
Tout a fait, c'est un oublie de ma part, merci de me l'avoir fais remarqué :) Je corrige tout de suite.
Boaf, c'est trivial, et à moins d'utiliser une lib externe, c'est pas cross-platform, donc bon. De tte manière, un mutex à l'initialisation, un à la libération, et c'est ok.
pdf, il y en a une. Pour l'html, ça viendra sans doute si j'arrive à faire cracher du xhtml strict à latex2html, et à lui faire comprendre l'utf-8.
# Initialisation du singleton
Posté par ggins . Évalué à 4.
En particulier, si tu stockes ton singleton comme une donnée statique de Manager::get, tu tombes pile dans ce cas de figure.
C'est pour cela qu'en général, on recommande de stocker un singleton sur le tas et de l'instancier à la volée la première fois qu'on le récupère. De cette manière, on ne court pas le risque de ne pas pouvoir l'initialiser parce qu'il a par exemple besoin qu'un autre singleton soit déjà instancié.
De plus, placer le constructeur en protected reste tout aussi "safe" et de cette manière tu te reserves le droit de disposer d'un autre singleton d'un type dérivé de Manager.
# Orth:
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
méthode désirant utiliser la classe de gestion devrai disposer -> devrait
si vous avez une demie-douzaine de classes -> demi-douzaine
ca peut etre sympa de mettre le mot "design pattern" en italique.
implémentation n'est pas dans le TLF. "Mise en oeuvre" serait mieux adapté et moins angliciste.
nous sommes assuré -> assurés.
thread-safe et multi-threadé qinsi que template pourraient aussi être mis en italique.
page 3:
biai -> biais
Voila.
J'ai pas fait ça pour faire chier, mais si tu te lances dans une série d'articles techniques, vaut mieux le faire proprement.
(Sinon, sans le code, je t'avoue que je pige rien :D)
# Ajout du Python ?
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Déjà, l'idée est très bonne et l'article est a l'air bon (pas trop le temps de le lire en détail là). Par contre, il serait intéressant de voir aussi les autres langages. Le principe est le même, mais chaque langage a ses spécificités.
J'avais justement répondu à une demande sur IRC d'implémentation de singleton en Python. Le premier jet est le suivant :
J'ai écrit une fonction Pouet pour faire croire qu'on instancie une classe Pouet alors qu'en fait on appelle la méthode getInstance() de la classe _Pouet.
Alternative, en utilisant un attribut privé (_instance) :
Cet exemple est plus propre je pense.
Voili voilou.
Haypo
PS: Oups, y'a pas moyen d'insérer du code en conservant l'indentation (<pre>) dans un commentaire LinuxFR, pas pratique pour le Python ...
[^] # Re: Ajout du Python ?
Posté par Amand Tihon (site web personnel) . Évalué à 2.
J'ai sûrement du piquer l'idée ailleurs, et vous pouvez voir le principe sur http://wiki.alrj.org/SingletonMeta (pour garder l'indentation). Par contre, ça manque de dommentaire :)
# lien utile
Posté par elloco (site web personnel) . Évalué à 2.
je n'ai pas encore eu le temps de lire ton article mais voici un lien que je trouve très utile : http://www.codeproject.com/cpp/singleton.asp
Ils font étape par étape la programmation du design pattern singleton en C++. Ils gèrent le thread-safe (qui n'est pas si trivial que ça) et proposent un moyen de détruire les objets singleton dans l'ordre inverse de leur création.
voilà voilà
@+
# Ok
Posté par Anonyme . Évalué à 2.
Pour le python, je ne commenterais pas: je viens à peine de débuter en python, donc forcément....
Enfin, merci pour le lien, je vais aller lire ça.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.