Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
classe Static ou singleton ?
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.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
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
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.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 !
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++
Oups je pensais que c'en était un, au temps pour moi
le getInstance() m'a induit en erreur
F.
Je ne souhaitais pas donner cette impression.
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é).
Un exemple de ce cas.
F.
Eh bien soit
Bonjour,
Voilà un lien qui donne quelques informations sur les différences. Si ça peut aider.
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".
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.
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
Répondre avec citation
Partager