J'ai une classe qui consiste uniquement de variables membres statiques et de méthodes statiques. Essentiellement, elle sert de classe utilitaire à usage général.
Est-ce une mauvaise pratique pour une classe de ne contenir que des variables membres statiques et des méthodes statiques ?
Non, je ne le pense pas du tout. C'est une mauvaise pratique que d'avoir une classe pleine de méthodes d'instance qui ne dépendent pas réellement d'une instance particulière. En les rendant statiques, on indique à l'utilisateur exactement comment elles doivent être utilisées. De plus, cela permet d'éviter les instanciations inutiles.
EDIT : Après coup, je pense qu'il est bon d'éviter d'utiliser les fonctionnalités du langage "juste parce que", ou parce que vous pensez que c'est la "façon Java de le faire". Je me souviens de mon premier emploi où j'avais une classe pleine de méthodes utilitaires statiques et l'un des programmeurs principaux m'a dit que je n'exploitais pas pleinement la puissance OO de Java en rendant toutes mes méthodes "globales". Elle ne faisait plus partie de l'équipe 6 mois plus tard.
Un constructeur privé par défaut empêche également la sous-classification de votre classe statique.
Y a-t-il une raison pour laquelle vous voudriez sous-classer une classe statique ? (je n'en vois pas... je ne suis pas un gourou du langage)
Empêcher la sous-classification dans ce cas est un "pour". Il est possible que quelqu'un d'autre travaillant sur votre projet puisse accidentellement essayer de sous-classer votre classe statique (par une faute de frappe ou un malentendu). En ajoutant un constructeur privé par défaut, vous donnez plus de sens à votre classe en imposant plus strictement la façon dont elle peut être utilisée.
Les méthodes statiques ne m'inquiètent pas beaucoup (sauf pour les tests).
En général, les membres statiques sont un problème. Par exemple, que se passe-t-il si votre application est en cluster ? Qu'en est-il du temps de démarrage - quel type d'initialisation a lieu ? Pour un examen de ces questions et plus encore, consultez cet article par Gilad Bracha.
Mais ne vous laissez pas emporter. Remarquez que la classe java.lang.Math ne concerne que les fonctions mathématiques. Vous pouvez aussi avoir une classe StringUtilities qui contient des fonctions courantes de traitement des chaînes de caractères qui ne font pas partie de l'API standard, par exemple. Mais si votre classe s'appelle Utilities, par exemple, c'est un indice que vous pourriez vouloir la diviser.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
28 votes
java.lang.Mathest une méthode 100% statique avec unprivateconstructeur (ne peut pas être instancié).0 votes
Je ne sais pas si cette question a déjà été posée dans ce forum. Mais est-ce une mauvaise pratique pour une classe de n'avoir que des champs statiques ? J'ai vu beaucoup de classes de ce type et à mon avis, elles ne correspondent pas à la POO.
0 votes
@ka3ak Les classes n'ayant que des champs statiques sont partiellement abordées dans quelques réponses à cette question.