Discussion :

[Targan]

Bonjour,

je code depuis peu en JAVA, et je vois une utilisation à gogo de méthodes statiques, et je me pose pas mal de question à ce sujet.

Est ce réellement propre de faire des classes comprenant que des méthodes statiques ?

Si cela n'est pas si moche que cela, n'en arrive-t-on pas à en abuser de partout ?

Finalement, quand les utiliser ? et quand ne pas le faire ?

Merci à tout âme charitable m'expliquant un peu tout cela, et m'aidant à prendre rapidement de bons reflexes.

ps : imaginons un cas pratique, l'écriture d'une classe permettant de compresser/décompresser/visualiser les fichiers d'une archive zip, je vois beaucoup d'exemple sur le net où tout est en static. Pourquoi ne pas en faire une vraie class à instancier avec des méthodes permettant de parametrer le taux de compression, d'ajouter les fichiers à traiter, le nom de l'archive etc ?

[gwinyam]

T'as plusieurs options au choix:
- La conception nécessite que ces méthodes soient statiques, là tu ne peux pas grand chose et c'est juste que tu tombes plus souvent sur ce cas,
- T'as à faire à des bras cassés qui ne savent pas faire ça autrement, ce qui est tout aussi envisageable.

Plus globalement, ça dépend vraiment du besoin.

Quand les utiliser? Quand la classe fournit des méthodes sans stocker des données ou encore quand la méthode n'utilise pas les données internes.

[tchize_]

un bon critère, a mes yeux, c'est la présence de champs statiques en grand nombre. Il existe plusieurs cas:

-> La méthode est indépendante de tout instance (exemple Integer.parseInt(String)), il n'y a alors pas de raison logique de ne pas la mettre en statique et elle ne manipule aucun champ
-> La "classe" est une classe utilitaire pour laquelle il n'y a pas de sens de créer plusieurs instance: on préfère en général à ce schéma un schéma de type singleton ou il existe une instance unique. C'est le cas, par exemple, avec des factory
-> La classe manipule plein de membres statique et a été codée par une équipe de bras cassé qui n'a toujours pas trouver comment utiliser un constructeur: le cas le plus courant amha

En pratique, la sonnette d'alarme devrait retentir quand
-> il y a beaucoup de classes statiques dans le projet (par opposition à 2/3 classes)
-> il y a beaucoup de champs statique dans ces classes
-> on commence à passer beaucoup de paramètres aux méthodes statiques, paramètres qui aureient eu leur place en temps que membre d'une instance de cette classe.

[Targan]

Je vais aller plus loin alors dans les explications de mon cas actuel.

En gros, je suis sur un projet où il y a plusieurs petites applis J2EE qui sont maintenues, et (enfin) il se décide de mutualiser du code :p

Bref une "librairie" se développe au fur et à mesure mais à tendance à être souvent bardée de méthodes statiques qui au final me fait souvent pensé à l'utilisation de DLL (pour moi venant plutot d'une programmation en win32, old school).

Là, je dois finalement y intégrer cette fameuse classe permettant de manipuler des fichiers zip. Pour le moment, 3 méthodes "classiques" à réaliser : compression, décompression mais surtout visualiser le contenu de l'archive.

Bref par habitude, n'ayant pas le reflexe, j'aurais fait une classe que j'aurais instancié, en y settant le taux de compression, en utilisant une méthode d'ajout des fichiers à compresser, le nom de l'archive etc etc...

Maintenant, en lisant vos commentaires et notamment :

-> La "classe" est une classe utilitaire pour laquelle il n'y a pas de sens de créer plusieurs instance: on préfère en général à ce schéma un schéma de type singleton ou il existe une instance unique. C'est le cas, par exemple, avec des factory

je me dis que des méthodes statiques doivent suffire puisqu'on rentrerait dans ce cas là. Une seule instanciation de la classe, des manips et basta.
Bref autant en faire du static, non ?

Qu'en pensez vous ?

Anyway, un grand merci pour vos réponses

[tchize_]

non on est pas dans le cas puis que une compresison =
1 série de paramètre par rapport à la compression
un ensemble de fichier à compresser
d'autres trucs éventuels


Donc clairement en "bon" design, il est plus logique d'avoir une instance par travail à effectuer. Plutot que de passer des tonnes de paramètres à une méthode statique. Toutes ces méthodes vont clairement tourner autour d'un "archive" qu'elle soit existante ou a créer.

[gwinyam]

La réponse est là:

Quand la classe fournit des méthodes sans stocker des données ou encore quand la méthode n'utilise pas les données internes.

-> La méthode est indépendante de tout instance (exemple Integer.parseInt(String)), il n'y a alors pas de raison logique de ne pas la mettre en statique et elle ne manipule aucun champ

-> La "classe" est une classe utilitaire pour laquelle il n'y a pas de sens de créer plusieurs instance: on préfère en général à ce schéma un schéma de type singleton ou il existe une instance unique. C'est le cas, par exemple, avec des factory

[Targan]

ah faut choisir là car vous vous contredisez :p

mais je pense avoir pigé...