Java: classe statique?
J’ai une classe pleine de fonctions utilitaires. L’instanciation d’une instance de celui-ci n’a pas de sens sémantique, mais je veux toujours appeler ses méthodes. Quelle est la meilleure façon de gérer cela? Classe statique? Abstrait?
- Sélectionnez distinct en utilisant linq
- Trouver une classe quelque part dans des dizaines de fichiers JAR?
- Pourquoi la classe enum est-elle préférée à la énumération standard?
- Quelles sont les différences entre struct et class en C ++?
- Pourquoi choisir Struct Over Class?
Constructeur privé et méthodes statiques sur une classe marquée comme finale.
Selon le grand livre “Effective Java” :
Point 4: Appliquer la non-fiabilité avec un constructeur privé
– Tenter de faire respecter le non-fiabilité en faisant un résumé de classe ne fonctionne pas.
– Un constructeur par défaut est généré uniquement si une classe ne contient pas de constructeurs explicites. Par conséquent, une classe peut être rendue non viable en incluant un constructeur privé:
// Noninstantiable utility class public class UtilityClass { // Suppress default constructor for noninstantiability private UtilityClass() { throw new AssertionError(); } } Le constructeur explicite étant privé, il est inaccessible en dehors de la classe. L’assertionError n’est pas ssortingctement requirejse, mais elle fournit une assurance si le constructeur est appelé accidentellement depuis la classe. Cela garantit que la classe ne sera jamais instanciée en aucune circonstance. Cet idiome est légèrement contre-intuitif, car le constructeur est fourni expressément pour qu’il ne puisse pas être invoqué. Il est donc judicieux d’inclure un commentaire, comme indiqué ci-dessus.
Comme effet secondaire, cet idiome empêche également la classe d’être sous-classée. Tous les constructeurs doivent invoquer un constructeur de super-classe, explicitement ou implicitement, et une sous-classe ne devrait pas avoir de constructeur de super-classe accessible.
On dirait que vous avez une classe d’utilitaire similaire à java.lang.Math .
L’approche est la classe finale avec constructeur privé et méthodes statiques.
Mais méfiez-vous de ce que cela fait pour la testabilité, je vous recommande de lire cet article
Les méthodes statiques sont mortelles à la testabilité
Juste pour nager en amont, les membres statiques et les classes ne participent pas à OO et sont donc mauvais. Non, pas mal, mais sérieusement, je recommanderais une classe régulière avec un modèle singleton pour l’access. De cette façon, si vous devez modifier le comportement dans tous les cas, ce n’est pas une réorganisation majeure. OO est ton ami 🙂
Mon $ .02
commentaire sur les arguments “constructeur privé”: allez, les développeurs ne sont pas si stupides; mais ils sont paresseux. créer un object puis appeler des méthodes statiques? ça n’arrivera pas
Ne passez pas trop de temps à vous assurer que votre classe ne peut pas être mal utilisée. Ayez confiance en vos collègues. et il y a toujours un moyen d’abuser de votre classe, peu importe comment vous la protégez. la seule chose qui ne peut pas être mal utilisée est une chose complètement inutile.
- Classe finale et constructeur privé (bon mais pas indispensable)
- Méthodes statiques publiques
Il est inutile de déclarer la classe comme static . Déclarez simplement ses méthodes static et appelez-les du nom de la classe normalement, comme la classe Math de Java.
De plus, même s’il n’est pas ssortingctement nécessaire de rendre le constructeur privé, c’est une bonne idée de le faire. Marquer le constructeur privé empêche les autres utilisateurs de créer des instances de votre classe, puis appelle des méthodes statiques à partir de ces instances. (Ces appels fonctionnent exactement de la même manière en Java, ils induisent simplement en erreur et nuisent à la lisibilité de votre code.)