CheckStyle dit: PMD dit: Qui a raison? Ou mettons-la de cette façon - quels sont les avantages et les inconvénients d'avoir un CTOR par défaut vide dans une classe?
9 Réponses :
J'aime la réponse de PMD. Moins le code le mieux. N'écrivez pas les constructeurs que le compilateur vous écrira pour vous.
Mon impression est que l'argument principal pour écrire le constructeur est que certains programmeurs pauvres qui ne comprennent pas la façon dont les constructeurs travaillent à Java pourraient trébucher sur votre code et être confus. Je n'aime pas l'écriture de code qui est inutilement obscur mais je n'aime pas non plus écrire de code haussié.
Mais c'est moi d'être obsessionnel et probablement déraisonnable. Il existe un monde de programmeurs d'applications dont l'accent est central est sur l'entreprise, et non sur la langue, et qui ne sont pas des experts en langage. Une technique de survie que beaucoup de personnes utilisent est d'avoir un style cohérent, que ce soit absolument nécessaire n'est pas le point.
Bien que je sois un peu comme un code moindre, mais que le constructeur par défaut facilite la définition d'un point d'arrêt chaque fois qu'il est nécessaire de déboguer.
Quoi qu'il en soit, puis-je vous rappeler que le site Web de PMD a également dit que la question est controversée :)
Je vais aller avec Checkstyle. Sans aucun constructeur explicite (noarg), personne ne saura que s'il est destiné ou non.
considère cette classe utilitaire:
Comment ne peut-il pas être destiné? Si elle est utilisée, et il n'y a pas d'autre constructeur, il a évidemment été destiné.
Vous devez regarder ailleurs pour voir si c'est utilisé et cela pourrait être refoulé à l'avenir dans tous les cas. Je dirais que l'explicitement déclare le constructeur par défaut, puis s'il s'agit d'une classe de bibliothèque avec uniquement des méthodes statiques, marquez le constructeur privé.
@andrewmu Oui, c'était mon intention.
Lorsque le constructeur par défaut est le seul constructeur, il est équivalent à 100% d'écrire explicitement avec un corps vide ou de l'omettre. Cependant, le compilateur ne générera pas de constructeur par défaut si vous avez des constructeurs explicitement définis, par défaut ou non. Cela signifie que si vous comptez sur le compilateur pour générer un constructeur pour vous, puis ajouter des constructeurs alternatifs, le constructeur par défaut disparaît. Personnellement, j'aurais tendance à laisser le compilateur faire la génération de toute façon; Si ce constructeur par défaut était utilisé, il générera des avertissements de compilation et est facile à ajouter à ce moment-là. Sinon, pourquoi le garder du tout?
Par défaut, le compilateur génère le constructeur par défaut pour vous, donc si vous ne souhaitez pas spécifier d'actions spéciales (l'initialisation des membres n'est pas le point ici), vous ne devez pas spécifier le constructeur.
Autre chose est que certaines classes devraient avoir un état cohérent. Par exemple, vous avez une classe de livres. Il n'y a pas de sens pour créer un livre sans titre, il est donc nécessaire de spécifier un constructeur avec le paramètre de chaîne: comme pour les constructeurs par défaut, ils peuvent être nécessaires si vous devriez être nécessaire si vous devriez Serialize votre classe ou l'utiliser dans marshalling / Nailarshalling (Jaxb nécessite un constructeur de défaut vide). Si ce n'est pas le point et que votre classe n'a pas ce qu'on appelle un état cohérent, le constructeur par défaut est donc absolument. inutile de déclarer. Vous devez vous rappeler que le constructeur par défaut est public par défaut, alors envisagez de décaltrer une explicite si vous souhaitez que certaines restrictions à cela. Si votre classe est plutôt longue, vous pouvez envisager de déclarer un constructeur par défaut vide pour augmenter la lisibilité.
Comme avec de nombreuses décisions qui sont «controversées», la vérité est que cela n'a pas vraiment d'importance. Écrivez le constructeur ou non. L'effet sur la qualité et la maintenance de votre code seront négligeables. Si vous codez avec d'autres, adoptez le même style de cohérence, mais sinon, faites ce que vous vous sentez comme.
+1 - On me rappelle des débats théologiques sur le nombre d'anges danser sur la tête d'une épingle ...
IMO maintenant lorsque vous faites un objet de la classe cube1, toutes les varibes d'instance de cet objet seront définies sur 10. Si vous N'utilisez pas de constructeur ici vos variables d'instance (longueur, largeur et hauteur) aura les valeurs par défaut (zéro dans ce cas). édité: [Ajout d'une autre chose] Si vous comptez sur le compilateur pour générer un constructeur par défaut pour vous et que vous souhaitez utiliser des constructeurs qui prennent des arguments / s de l'utilisateur, vous devez définir le constructeur par défaut sinon le compilateur générera une erreur. N'oubliez pas : compilateur fait le constructeur par défaut pour votre classe uniquement si cette classe ne contient aucun autre constructeur. La classe doit définir un constructeur car si vous comptez sur des constructeurs par défaut, les variables d'instance auront des valeurs par défaut (telles que zéro pour les entiers, null pour une chaîne, etc.). Si vous souhaitez définir des variables d'instance à une valeur par défaut chaque fois qu'un objet pour cette classe est créé, la définition d'un constructeur vous-même peut être un bon choix dans ce cas. (À condition que vous ne voulez pas utiliser les méthodes getter & setter)
Eh bien, vous pouvez également initialiser les champs dans lesquels vous les déclarez, comme Longueur Int privée = 10; qui rend sans soucie les choses plus claires car elle lie le champ et sa valeur par défaut ensemble.
Une chose que j'ajouterai est que s'il n'y a pas de constructeur spécifié, il existe un constructeur par défaut implicite que le code peut dépendre de.
Ensuite, lorsque vous ajoutez un constructeur spécifique, le code ne peut plus compiler - ni même pire, le code ne fonctionnera pas (peut être une dépendance réfléchissante sur le constructeur sans paramètre - la plupart des outils ORM nécessitent un constructeur par défaut pour des entités persistantes. ).
C'est pourquoi vous devez expliquer explicitement le constructeur par défaut si nécessaire.
Je suis enclin à aller avec un code d'écriture uniquement quand il est nécessaire. Si vous n'avez pas besoin d'autres constructeurs, allez avec le compilateur le générer pour vous. Sinon, code tous les constructeurs dont vous avez besoin.
C'est juste un problème de style. Le code généré est le même.
Fait intéressant, ces 2 opinions ont des places commutées entre les outils ... PMD vous exigent maintenant un constructeur par défaut pendant que CheckStyle ne se souciait pas vraiment.