Discussion :

[phoeniix07]

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

[gifffftane]

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 ?

[natha]

Quand à l'utilitaire statique, il ne se justifie vraiment que dans de très rares cas.

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.

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...

[gifffftane]

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.

[natha]

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

[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.