Version imprimable
bonjour a tous !
alors voila j'ai un petit probleme
j'ai besoin d'une classe qui me sert de "boite a outil" pour la manipulation de fichier (creation repertoire, suppression)
des lors vaut il mieux que j'utilise un singleton ou un classe static ?
merci d'avance
Pour moi ni l'un, ni l'autre : utilise un objet, tout simplement.
Le pattern du singleton est de plus en plus considéré comme un antipattern. Si une appli ne veut qu'un objet d'une classe, elle ne prend qu'un objet, tout simplement, et elle le gère. Pourquoi obliger, limiter le nombre d'instances à une ? C'est plus difficile à tester, plus difficile à hériter, cela cache les dépendances entre modules (en fait cela revient à une des horribles variables globales du temps jadis), et c'est le mic-mac assuré avec les classloaders, parce que les singletons utilisent un espace statique dans le cadre d'un espace d'instance.
Quand à l'utilitaire statique, il ne se justifie vraiment que dans de très rares cas.
Si tu y tiens vraiment, prends la classe utilitaire statique, c'est plus facile que le singleton.
À part ça, pour la gestion des fichiers, la classe File ne te suffit pas ?
Très rares ? J'ai des dizaines d'utilitaires statiques, certains sont des factory pour créer mes composants, d'autres des utilitaires de manipulation de String, de fichiers, d'autres me fournissent des méthodes spécifiques auxquelles j'ai besoin dans plusieurs endroits de mon code.Citation:
Envoyé par gifffftane
Je ne vois pas pourquoi ça ne se justifierai pas dans tous ces cas. C'est sûrement beaucoup plus propre d'avoir des méthodes statiques pour tout ça.
Quand au singleton, là je l'utilise aussi, mais très très rarement.
Parfois il est quand même beaucoup plus simple d'avoir une instance unique accessible statiquement depuis toute l'application plutôt que d'avoir à passer l'instance créée à toutes les classes appelées...
Si tu en es content, alors, c'est bon. Il y a plusieurs façons de programmer, je ne vais certainement pas m'amuser à chercher la petite bête, et d'ailleurs, si je puis me permettre, je conseillais in fine à notre ami d'utiliser l'approche statique.
Disons que je ne connais pas d'autre façon, j'ai quelques lacunes au niveau des différents patterns utilisables. Je suis toujours preneur des idées meilleures, alors si t'as des suggestions ;)Citation:
Envoyé par gifffftane
Pour moi le meilleur pattern est ce que l'on ressent. Si tu vas bien avec les statiques, si tu fais du code clair avec ça, c'est parfait.
Pour ma part, en Java, je trouve que l'expression de valeurs statiques est mal faite, au niveau du code, au niveau de l'héritage. Mais je reconnais que quelques règles simples permettent d'écrire tout de même du bon code. Quand j'écris par exemple Math.min(a, b), je dois admettre que c'est clair. J'aurais préféré math.min(a, b) (avec une instance), mais c'est du chipotage.
Pourquoi préfère-je éviter la forme statique ?... Dans le comportement d'un logiciel, il me semble que tout dépend d'un contexte, contexte qui est multiple, est variable.
Au départ, quand on démarre une appli, on n'a pas conscience de cela, et on a l'impression qu'il n'y a qu'un seul contexte fixe : on programme alors avec des valeurs statiques, qui expriment ce que l'on croit être sûr. Puis, lorsque les choses s'approfondissent, le développeur reçoit de ses clients et utilisateurs des précisions, et ce que l'on croyait sûr le devient moins. Littéralement, les contextes se multiplient.
Il me semble que c'est plus facile de se débrouiller alors, de faire du refactoring, lorsque le contexte est exprimé avec des instances d'objets, qu'avec des valeurs statiques.
Oui alors les valeurs statiques beurk ! J'évite au max ! Le pire que j'ai fait et qui m'a vacciné c'est un listener static global à 5 écrans... gros problème de libération mémoire ;)Citation:
Envoyé par gifffftane
Les méthodes utilitaires statiques par contre on ne peut pas s'en passer car beaucoup de choses ne nécessitent pas une instance. :)
Abandonner le singleton ? Ou ne plus l'utiliser ?
On fait quoi de l'économie de mémoire : mettons une application avec 50000 éléments, bah, ces 50000 éléments doivent avoir une référence à l'objet unique (donc 4 bytes x 50000 éléments, cool, 200k de paumés pour... rien) ? Ou au moins une référence qui permet d'accéder à l'objet unique ? Allons donc... on a de la chance d'avoir souvent assez de mémoire pour se le permettre, mais l'approche est un peu... désinvolte, non ?
Le pattern singleton est toujours bien montré du doigt. Il ne faut pas en abuser, effectivement, mais il ne faut pas le sous-utiliser non plus. De là à dire qu'il s'agit d'un anti-pattern, je crois que ça vient d'une mode soi-disant bien pensante qui vient du supérieur d'un pauvre gars qui utilisait trop les singletons et qui en a eu ras la casquette.
Salut,
Les méthodes statiques ont leurs avantages, le singleton a les siens.
Exemple concret : le singleton Calendar... Comment auriez vous fait la classe Calendar sans singleton ?
Quel constructeur auriez vous fait ? Un contructeur par défaut publique qui appelle un constructeur privé ?
Le singleton a l'avantage d'offrir une "transparence". On récupère une instance de l'objet, on n'en crée pas une. Quand je débutais en java, faire un getInstance(), même si je ne connaissais pas le pattern, je savais que derriere je ne créais pas un objet...
Maintenant pour ce qui est des classes statiques, j'en use mais n'en abuse pas. C'est souvent pratique il est vrai lorsqu'on a une tache récurente à faire dans plusieurs objets différents, comme des traitements sur des String ou autres, qui ne nécessitent pas une instance d'un objet particulier sur laquelle s'executer...
F.
Objet unique : ici c'est une hypothèse de base, non ? Donc forcément c'est la meilleure, c'est indiscutable.
Dès lors que l'objet est unique par hypothèse, il est bien évident qu'il faut prendre un singleton, ou une classe utilitaire statique.
Bon.
Prenons maintenant le cas où il apparait qu'il y a deux objets uniques par hypothèse... Là c'est moi qui ai raison. É ben on a bien avancé.
J'admets qu'il y a eu une mode singleton, qu'il arrive maintenant une mode anti-singleton, sans doute effectivement à cause d'exagérations (comme pour XML peut être), et qu'en toutes choses il faut rester pragmatique. (tient, au fait, il y avait eu la mode des pragma à un moment, où c'est-il passé ça ? )
Salut,
Pourrais tu donner un exemple concret de ce que tu avances ?
F.
Je vois pas le problème ! C'est pas un singleton ! On en revient à ce que j'ai dit, dans le cadre d'un besoin d'une unique instance pour l'entièreté de l'application, le singleton, y'a rien de tel. Après si le développeur place un seul singleton de parsing alors que son appli ne fait que du parsing et en grande quantité, et qu'en plus elle est répartie sur plusieurs threads, là oui, pas besoin de singleton, mais d'un nombre limité d'instances. Il faut bien entendu relire le but du singleton, et l'appliquer à bon escient. C'est de la responsabilité du développeur.Citation:
Prenons maintenant le cas où il apparait qu'il y a deux objets uniques par hypothèse... Là c'est moi qui ai raison. É ben on a bien avancé.
De là à en faire une chasse au sorcière comme tu sembles le faire...
Salut,
Attention car Calendar n'est pas un singleton !Citation:
Envoyé par mavina
Pour un singleton la méthode getInstance() signifie "get THE instance" et renvoi une instance unique.
Dans la classe Calendar, getInstance() crée à chaque appel une nouvelle instance de Calendar selon la locale (BuddhistCalendar, JapaneseImperialCalendar ou GregorianCalendar). Ici cela signifie plutôt "get AN instance"...
a++
:roll: Oups je pensais que c'en était un, au temps pour moi :? le getInstance() m'a induit en erreurCitation:
Envoyé par adiGuba
F.
Je ne souhaitais pas donner cette impression.Citation:
Envoyé par dingoth
Dans le cas où il est utile, soit, il est utile. Et si c'est de la responsabilité du programmeur pour le cas où on l'a cru utile et où il se révèle inutile, alors le principe est effectivement sauvegardé, à défaut du programmeur.
Je tente de ma placer dans un cadre où la responsabilité du programmeur est de faire évoluer le logiciel, pour le cas où il y a eu une erreur de conception. Et je dis que c'est plus facile lorsque le contexte est adaptable à un cas particulier. Le singleton est forcément général à une appli, on ne peut pas le faire évoluer sans risquer d'influer sur toute l'appli.
Cela me parait être un défaut, mais ce n'est pas pour cela que je voudrais le faire apparaître comme une sorcière.
Heu... à qui tu parles ? Et si c'est à moi, exemple de quoi ? (je suis paumé).Citation:
Envoyé par mavina
Un exemple de ce cas.Citation:
Envoyé par gifffftane
F.
Eh bien soit :) Mais dans ce cas, pourquoi ne pas l'avoir précisé dès le début plutôt que de dire que " le singleton, cémal " sans donner une argumentation qui permettrait réellement au développeur de se faire une idée : "attention, est-ce que je réfléchis bien à l'avenir en plaçant cet objet comme singleton ?"
Bonjour,
Voilà un lien qui donne quelques informations sur les différences. Si ça peut aider. :D
http://www.developpez.net/forums/showthread.php?t=68523
Pour ma part, je trouve l'utilisation du singleton particulièrement pratique, sans en abuser pour autant. Il arrive que ce pattern soit particulièrement bien adapté lorsqu'on ne veut pas multiplier des instances pour un object qui "ne le mérite pas" :D.
Le "ne le mérite pas" demande malgrès tout d'être attentivement étudié.
Salut,
je lisais un article tres interressant sur le Singleton, sa presentation dans le bouquin du GoF, les anti-patterns.Citation:
Envoyé par dingoth
En gros: il est possible de critiquer le bouquin avec le recul qu'on a maintenant. La presentation du Singleton, notamment dans sa partie applicabilite, laisse trop la porte ouverte a l'utilisation abusive de variables globales (cémal).
Je fais le constat suivant: je fais partis de ces personnes qui ont fait de la singletonite, je suis pas le seule, les personnes que je considere les plus competantes de mon entourage ont fait les meme erreurs. Et je pense qu'on ne sera pas les derniers.
Design pattern = work in progress
Ps: qui a entendu parler d'une nouvelle edition du bouquin du GoF?
Ps: je recherche la ref de l'article en question
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.
Ce qui est une erreur vis à vis du pattern singleton.Citation:
Envoyé par divxdede
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é.Citation:
Envoyé par adiGuba
Oui on est tout à fait d'accord.Citation:
Envoyé par divxdede
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. ;)
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.Citation:
Envoyé par ndp
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.Citation:
Envoyé par divxdede
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.
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.Citation:
Envoyé par divxdede
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.
Tu laisses un constructeur avec une vision package.Citation:
Envoyé par gifffftane
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 ?"
Ce qui est une solution au problème du test devient une erreur de conception.Citation:
Envoyé par divxdede
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.Citation:
Envoyé par natha
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.
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:
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:
2
3
4
5
6
7
8
9
10
11
Code:
2
3
etc.Code:
2
3
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.
Travaillant avec des stagiaires et des débutants j'ai un peu de mal à conserver intact ce genre de principes :)Citation:
Envoyé par divxdede
La proposition Java7 des superpackages pourrait être une solution à ce genre de problèmes.
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...
Citation:
Envoyé par natha
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.Citation:
Envoyé par divxdede
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...
:arrow: Cela n'aurait pas été possible avec des méthodes static !
a++
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.
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" .Citation:
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.
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)
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).
100% d'accord.Citation:
Envoyé par eclesia
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. :aie:
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).