Discussion :

[divxdede]

my 2'cents

Effectivement, en général quand on découvre ce pattern on s'en sert a foison.
Et souvent dans des cas où ce dernier n'est pas rééllement adéquat.

L'utilisation abusive du singleton va généralement de paire avec la tendance "je veux économiser ma mémoire et éviter les GC".

Or on se rends compte avec du recul que d'instancier des objets à trés courte durée de vie (restant dans la mémoire young) ne pose quasiment aucun problème de performance.

Le singleton est un trés bon pattern qu'il faut apprendre à maitriser car dans sa conception il verrouille pas mal l'architecture du programme.

En tout cas, personnellement je continue de m'en servir quand j'en ressens le besoin sans prendre aucune considération de mode ou tendance.

[adiGuba]

L'utilisation abusive du singleton va généralement de paire avec la tendance "je veux économiser ma mémoire et éviter les GC".

Ce qui est une erreur vis à vis du pattern singleton.

Ce pattern n'a pas pour objectif d'économiser de la mémoire mais de fournir un accès simple et rapide à un objet unique en mémoire...


Perso je l'utilise souvent sur la fenêtre principale de mon interface graphique, afin de pouvoir interagir avec de n'importe quel endroit de mon application sans avoir à me la trimballer un peu partout...


a++

[divxdede]

Ce qui est une erreur vis à vis du pattern singleton.

Ce pattern n'a pas pour objectif d'économiser de la mémoire mais de fournir un accès simple et rapide à un objet unique en mémoire...


Perso je l'utilise souvent sur la fenêtre principale de mon interface graphique, afin de pouvoir interagir avec de n'importe quel endroit de mon application sans avoir à me la trimballer un peu partout...


a++

Tout à fait, mais c'est un travers que j'ai commis en mon temps, et en discutant beaucoup j'ai constaté qu'on fait presque tous cet amalgame à un moment donné.

[adiGuba]

Tout à fait, mais c'est un travers que j'ai commis en mon temps, et en discutant beaucoup j'ai constaté qu'on fait presque tous cet amalgame à un moment donné.

Oui on est tout à fait d'accord.

Je soulignais seulement que c'était une erreur d'utilisation du pattern plutôt qu'un défaut du pattern en lui même

a++

PS : L'optimisation prématurée est la source de tous les maux.

[ndp]

certaines mauvaises utilisation des patterns proviennent des patterns eux-meme

[divxdede]

certaines mauvaises utilisation des patterns proviennent des patterns eux-meme

Je préfére revoir un projet ou des singletons ont été utilisés a mauvais essient plutôt qu'un projet où il existe un couplage trés fort entre tout les objets.

Pour dire que d'une façon générale, on ne peut pas accuser un pattern d'être la source d'une mauvaise qualité de code pour dé-résponsabiliser le développeur (ou l'analyste).

Un mauvais usage provient que d'une mauvaise compréhension de l'entité manipulé, on ne peut pas accuser le pattern.

[ndp]

Je préfére revoir un projet ou des singletons ont été utilisés a mauvais essient plutôt qu'un projet où il existe un couplage trés fort entre tout les objets.

Pour dire que d'une façon générale, on ne peut pas accuser un pattern d'être la source d'une mauvaise qualité de code pour dé-résponsabiliser le développeur (ou l'analyste).

Un mauvais usage provient que d'une mauvaise compréhension de l'entité manipulé, on ne peut pas accuser le pattern.

Je voulais mettre le focus sur un aspect tres interessant des patterns: ce sont des work in progress, ils doivent evoluer avec le temps.

Ils sont base sur l'experience, et en prenant l'exemple du Singleton presente dans le GoF, il est logique que par rapport a cette version (1995?), on peut avoir un certain recul et lui faire beneficier de 13 annees suplementaire de retour sur experience. Tout le monde c'est planter avec un Singleton (bon j'exagere), on peut a juste titre prendre un peu de recul par rapport a sa presentation, notamment au niveau applicabilite.

Je préfére revoir un projet ou des singletons ont été utilisés a mauvais essient plutôt qu'un projet où il existe un couplage trés fort entre tout les objets.

personnelement un truc, qui ma vraiment fait marrer, c'etait un blog, ou on presentait un system.out.println implemente avec une dizaine de design patterns et au final on ne comprenait plus la fonctionnalite du code.

[gifffftane]

Ah je vois que des gens plus posés que moi viennent apporter des précisions limitatives au pattern. Ils y mettent un peu de diplomatie, je les remercie. Il faut dire qu'on a l'expérience, qu'on a fait des erreurs, qu'on contribue à l'amélioration générale, et ça passe mieux. Bon.

Le seul ennui pour donner un exemple concret est que ça fait si longtemps que j'ai pas construit de singleton ou de méthodes statiques que j'ai oublié. Aujourd'hui je reviens un peu aux méthodes statiques, pour faciliter la construction d'objets, et il faut attendre un peu pour que j'en tire une expérience qui puisse contribuer à l'amélioration générale.

Le piège qui m'avait fait jeter le singleton aux orties est que plusieurs fois j'avais cru qu'un objet était unique pour une appli, et que finalement il apparaissait en cours de développement qu'il ne l'était pas. J'étais obligé de tout repasser en instances multiples, et c'était la poisse.

Par exemple, pour faire des tests automatisés, j'étais coincé par le singleton ; je ne pouvais pas faire varier son comportement selon les cas bizarres qui pouvaient apparaître puisque... il était bon.

Par exemple aussi, les problèmes de configuration. Au départ on vous jure qu'il y aura des configurations minima, et qu'il n'y aura qu'un fichier de propriétés. Donc on fait un singleton, qui est la solution la plus évidemment pratique : cet objet est accessible de partout, donc capable de tout configurer.

Puis on vous dit qu'il faudrait une GUI pour faciliter la configuration, puis on vous dit que la GUI est prioritaire sur le fichier de configuration, sauf que quelques fois on veut configurer par accés réseau, que lorsque l'utilisateur donne une config érronée alors il faut reprendre la config par fichier de properties, que telle partie doit être configurée par la GUI, l'autre par les properties, etc, etc, etc.

Aujourd'hui je pense que c'est une erreur quasi philosophique de croire qu'une chose puisse être unique (toutes considérations religieuses mises à part), et j'essaie d'expliciter le contexte, et de montrer clairement les dépendances. Donc, lorsqu'il y a un système de configuration, je le passe en paramètre d'une façon ou d'une autre.

[divxdede]

Par exemple, pour faire des tests automatisés, j'étais coincé par le singleton ; je ne pouvais pas faire varier son comportement selon les cas bizarres qui pouvaient apparaître puisque... il était bon

Tu laisses un constructeur avec une vision package.
Ton test unitaire se trouvant dans le même package, tu peu créer des instances multiples pour tes tests.

Ceci dit, je suis d'accord avec ta reflection, il faut vraiment se poser la question "est il rééllement légitime que cet objet soit unique ?"

[natha]

Tu laisses un constructeur avec une vision package.
Ton test unitaire se trouvant dans le même package, tu peu créer des instances multiples pour tes tests.

Ce qui est une solution au problème du test devient une erreur de conception.
Un singleton DOIT être une classe finale et avoir un constructeur privé !
Enfin je ne sais pas si c'est dans sa définition mais ça me parait logique si on veut justement éviter les problèmes où on croit qu'il n'y a qu'une instance et où on se rend compte qu'il y en a plusieurs...

Personnellement mon dernier singleton est une classe de préférences mais ne contenant pas elle-même les préférences car j'utilise les classes java.util.pref. Mon singleton me permet surtout d'avoir des getters/setters qui ont des noms sympatiques et de centraliser les clés des propriétés (c'est une Map).

[divxdede]

Ce qui est une solution au problème du test devient une erreur de conception.
Un singleton DOIT être une classe finale et avoir un constructeur privé !
Enfin je ne sais pas si c'est dans sa définition mais ça me parait logique si on veut justement éviter les problèmes où on croit qu'il n'y a qu'une instance et où on se rend compte qu'il y en a plusieurs...

Personnellement mon dernier singleton est une classe de préférences mais ne contenant pas elle-même les préférences car j'utilise les classes java.util.pref. Mon singleton me permet surtout d'avoir des getters/setters qui ont des noms sympatiques et de centraliser les clés des propriétés (c'est une Map).

Quelle soit finale est effectivement conseillée et ne géne pas dans l'exemple précedent.
Mais effectivement avoir un constructeur avec un accés package est un risque vis à vis de l'intégrité du singleton. Cependant, tu peu partir du principe que le package respecte le contrat voulu.

[CyberChouan]

Déclarer les singletons comme classes finales, certes.

Mais je ne comprends pas pourquoi les singletons sont si décriés. J'ai travaillé sur un projet où on les a utilisés de la manière suivante:

Une classe "utilitaire" abstraite paramétrée par un type, dans le style suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public Abstract class GestionPersistance<E> {
   public void sauvegarderObjet(E objet) {
      // code
   }
 
   public E chargerObjet(String identifiant) {
      // code
   }
 
   // etc.
}

Autant de singletons étendant cette classe abstraite, afin de gérer dans une classe utilitaire la persistance de plusieurs types d'objets avec 0 lignes de codes (la partie métier étant au niveau de la classe abstraite):

Code :

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

1
2
3
public class PersistanceCarottes extends GestionPersistance<Carotte> {
   // déclaration du singleton
}

Code :

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

1
2
3
public class PersistancePoireaux extends GestionPersistance<Poireau> {
   // déclaration du singleton
}

etc.

Sans être un expert en conception, cette manière d'utiliser la généricité et les singletons ne m'a paru foncièrement mauvaise... et permettait d'avoir simplement des classes dédiées au traitement de nos différents types d'objets sans pour autant avoir de copié-collé de code.

Evidemment, je vois venir l'objection... il suffisait d'une classe utilitaire statique gérant la persistance d'une interface "fruits et légumes", que les Carottes, Poireaux, et autres Choux auraient tous implémentés, pour ne plus avoir besoin de ces singletons. Mais dans le cas qui nous occupait, nous n'étions pas maîtres des objets à traiter, qui n'implémentaient aucune interface commune.

[natha]

Cependant, tu peu partir du principe que le package respecte le contrat voulu.

Travaillant avec des stagiaires et des débutants j'ai un peu de mal à conserver intact ce genre de principes
La proposition Java7 des superpackages pourrait être une solution à ce genre de problèmes.

[gifffftane]

Oui, c'est un peu l'approche d'hibernate, il me semble (partie métier dans des sous classes de la classe gérant la persistence).

Il y a toutefois une grosse différence philosophique : avec Hibernate PersistanceCarottes devient Carotte, tout simplement. Il se justifie en effet que Carotte ne soit que Carotte, puisque la persistance est gérée par GestionPersistance. Et il devient bien évidemment inutile que Carotte soit un singleton...

Pourquoi avez-vous eu besoin de prolonger le singleton GestionPersistance par un singleton pour chaque type de données ?... En théorie, cela devrait être inutile, puisque la gestion de la persistance est précisément gérée par GestionPersistance ?

Si toutefois on admet votre approche, pourquoi contraindre les PersistanceCarottes, GestionPersistance et assimilé à être des singletons ? Votre appli n'en utilise qu'une instance, mais quelle raison particulière y aurait-il de le contraindre ?

Parce qu'il n'y a qu'une seule base (je présume) ?

Il est mieux, à mon avis, de rendre compte de l'aspect une seule base en se donnant une seule instance de gestion de cette base, sans contraindre son unicité, ce qui oblige à la transmettre explicitement aux objets qui en ont besoin. L'approche singleton, sous prétexte de résoudre le problème on est sûr qu'il n'y a qu'une base et on veut pas de dépandances, rend accessible la base de partout, il est plus difficile de contrôler, ou même vérifier, qui l'utilise et pourquoi.

La base devient au mieux un utilitaire transparent, ce qu'elle n'est pas, au pire une variable globale cachée, et cela devient ingérable.

De plus, placer des PersistanceCarottes propre à chaque contexte donne l'opportunité d'agir selon ce contexte - faire des mini-cache, par exemple. C'est plus difficile avec l'approche singleton, à moins d'avoir un objet qui gère tous les contextes, ce qui est plutôt le rôle de l'objet d'accés à la base elle même.

Enfin bon...

[adiGuba]

Un singleton DOIT être une classe finale et avoir un constructeur privé !

Mais effectivement avoir un constructeur avec un accés package est un risque vis à vis de l'intégrité du singleton.

Je ne suis pas d'accord avec cela ! Un singleton doit simplement permettre un accès aisé à une instance unique d'une classe. Mais rien n'empêche d'étendre la classe pour proposer une autre implémentation.

Au contraire l'héritage est parfois directement intégré dans le singleton. Le meilleur exemple à mes yeux est la classe Toolkit qui est une classe de base dont hérite toutes les implémentations, et la méthode getDefaultToolkit() renvoi une implémentation selon la configuration et le système d'exploitation...


Cela n'aurait pas été possible avec des méthodes static !

a++

[natha]

Ah ok, bien vu.

Aimant bien sécuriser mon code au maximum je préfère quand même avoir des singletons finaux et aux constructeurs privés. Mais ok, ça ne défini pas un singleton.

[bobuse]

Je vous recommande la lecture de cet article fort intéressant :
http://tech.puredanger.com/2007/07/0...ate-singleton/

Depuis, j'essaie de plus en plus d'éviter d'utiliser un singleton, et de plutôt utiliser de l'injection de dépendance. C'est vrai que c'est un peu moins pratique, mais ça me paraît plus propre.

[eclesia]

Je vous recommande la lecture de cet article fort intéressant :
http://tech.puredanger.com/2007/07/0...ate-singleton/

Depuis, j'essaie de plus en plus d'éviter d'utiliser un singleton, et de plutôt utiliser de l'injection de dépendance. C'est vrai que c'est un peu moins pratique, mais ça me paraît plus propre.

Le livre "Java Efficace" de Joshua Bloch parle de l'utilisation correct des singletons, et donne l'avis inverse. (je ne vais pas taper ici le chapitre sur le sujet) personnellement j'y accorde plus de credit que quelqu'un qui des le depart dit : "This entry inaugurates a new series on patterns that I hate" .
Je pense plutot que cette personne utilise le singleton pour faire du pseudo-procedural, ce qui le conduit aux 5 erreurs qu'il cite. (qui pour moi n'en sont pas)

[gifffftane]

Je mettrais mon hum assis entre deux chaises sur ce coup là.

Chaise gauche : j'admets que l'injection de dépendance n'est certainement pas une solution aux problèmes que poserait le singleton. La solution aux problèmes que pose le singleton est de ne pas l'utiliser, c'est tout. L'injection de dépendance est à utiliser... pour l'injection de dépendance ; son formalisme peut ressembler à celui du singleton, il n'empêche que ce n'est pas le même sujet.

Chaise droite : les problèmes indiqués par ce lien me semblent justes, et ils existent y compris si on utilise correctement le pattern du singleton. (mais j'admets ne pas trop savoir ce que peut signifier l'expression utilisation correcte du singleton).

[pseudocode]

Je pense plutot que cette personne utilise le singleton pour faire du pseudo-procedural, ce qui le conduit aux 5 erreurs qu'il cite. (qui pour moi n'en sont pas)

100% d'accord.

Je vois souvent que la "technique" du singleton est utilisée pour représenter une spécificité "métier": il n'existe qu'une instance de X.

Un exemple (extreme) serait de créer la classe "Jupiter" et d'en faire un singleton car dans la réalité il n'y a qu'une seule planete qui se nomme ainsi.

A mon sens, une classe ne doit pas implémenter ce genre de pattern que s'il y a un risque "technique" d'outrepasser sa responsabilité (= son contrat).