J'ai vu les deux approches utilisées mais n'ont jamais entendu dire qu'une manière est préférée sur l'autre pour une raison particulière pour une raison particulière. VERSUS P> public String toString() {
return getField1() + " " + getField2();
}
7 Réponses :
Utilisez des getters, si vous les avez!
Peut-être, un jour, vous modifiez le code de sorte qu'un getter renverra non seulement la valeur des champs, mais faire quelque chose de plus ou créer le résultat d'une manière différente. Ensuite, vous serez plus heureux que vous ayez utilisé get de systématiquement.
Mais comme d'habitude, il y a des extemptions de mon conseil - que vous attendez-vous de la méthode Tostring () si vous autorisez le dépassement des méthodes de getter, voulez-vous qu'il utilise les champs de classes ou le résultat du - peut-être remplacer - méthode getter.
Donc, comme d'habitude, cela dépend, mais j'utiliserais des getters à moins d'avoir une bonne raison d'accéder directement aux champs directement.
Vous avez mis à la fois les points de vue. Mais la question reste-t-elle toujours la question que nous devrions utiliser :)
Utiliser des getters à Tostring est une overcilleuse. Et vous ne devriez pas utiliser Tostring à des fins non déboguées.
Re: "Et ensuite, vous ne devriez pas utiliser Tostring à des fins de débogage." - Quel?
Il existe de nombreuses instances où l'utilisation de Tostring () est valable en dehors des objectifs de débogage. Par exemple, si vous avez une classe XML, il est parfaitement raisonnable d'attendre .Tostring () pour renvoyer une représentation de chaîne dans XML. Même avec les classes d'URL ou d'URL, Tostring () serait la méthode raisonnable non étonnante prévue de fournir une représentation de chaîne de l'objet.
Ou, toutes les autres classes. Il y a une raison que tostring () est membre de la classe objet .
Pourquoi les bowvotes? @DANBEN et @Fuzzy: lisez le javadoc pour objet.tostring (). Cela ne garantit rien. Vous n'avez pas à le remplacer. Donc, si votre Tostring () appelle tout autre chose que vous ne savez jamais ce que vous pourriez obtenir. La 3ème partie des API peut changer ce truc sur un caprice. Si je produisais une chaîne XML, ma méthode serait appelée TOXMLString. Si vous allez représenter un objet en tant que chaîne à un utilisateur final, il y a toutes sortes de choses à prendre en compte: langue, sécurité / permissions, préférences d'affichage, etc. Vous mettez toute cette logique dans Tostring?
Pourquoi utilise-t-on des getters à Tostring () une overcilleuse? La plupart des compilateurs modernes sont suffisamment intelligents pour aligner ces appels à des fins d'optimisation
@ Z5H: Non, vous n'avez pas à remplacer Tostring () , mais il est recommandé. La principale raison de ceci est que Tostring () est appelé par system.out.println . Voir Java efficace, point 9 pour une description complète.
@Fuzzy Lollipop a déclaré: «Par exemple, si vous avez une classe XML, il est parfaitement raisonnable d'attendre .Tostring () pour renvoyer une représentation de chaîne dans XML». Je suis intéressé par un exemple de certaines API cultivées non à la maison. Pouvez-vous me montrer un (de SAX, DOM etc ...)?
Je ne peux pas vraiment améliorer la réponse de Z5H. J'ai supposé que c'était une connaissance courante que Tostring () ne doit pas être utilisé pour la production applicative.
Utilisation des méthodes d'accesseur Pourraient être préférées s'ils fournissent une logique supplémentaire au-dessus de simplement renvoyer la valeur du champ (comme la barre de la majuscule, ou quelque chose comme ça). Si votre classe est conçue pour être étendue, j'aurais tendance aux accesseurs car ils peuvent être remplacés.
Je fais habituellement mes pojos / tos final . J'ai aussi rarement vu toute logique supplémentaire dans une getter.
Ah bon? J'ai vu des getters qui ont généré des valeurs qui n'étaient même pas des propriétés explicites de l'objet en question.
De plus, si vous avez un objet final , cela ne tombe clairement pas sous "conçu pour être prolongé".
Avez-vous des raison pour utiliser les méthodes getter? Est-ce qu'ils font quelque chose d'intéressant?
... ou vous les utilisez simplement pour exposer des données internes sans rendre les champs eux-mêmes publics (encapsulation de l'homme pauvre)?
Si le premier, alors oui par tous les moyens les utilise ici aussi! Si ces derniers, alors cela n'a pas d'importance - vous voudrez peut-être les utiliser de toute façon, juste au cas où vous leur donnez un objectif réel, mais cela ne fera pas un peu de différence autrement. < / p>
Je préférerais l'approche pour accéder directement aux variables privées. IMHO Les méthodes getterter augmentent l'encombrement.
Utilisation de String.Format ("% S% S", ceci.getfield1 (), ce.getfield2 ()); serait la meilleure façon de le faire, car le . getxxx () Les méthodes peuvent avoir une logique dans laquelle vous souhaitez que vous souhaitiez de convertir des références nulles dans des chaînes vides ou une valeur par défaut que vous ne recevriez pas en accédant à l'aveugle des instances privées. C'est le moyen le plus sûr de le faire, juste au cas où quelqu'un viendra et ajoute la logique à une méthode .getxxx () et ils ne pensent pas à mettre à jour le .tostring () Implénation.
Si votre classe a des getters et des configurations pour champs, vous devez être cohérent tout au long de la mise en œuvre de cette classe dans laquelle vous utilisez des getters et des configurateurs ou accédez directement aux champs. Il n'a généralement pas de sens de mélanger les niveaux d'abstraction. Sinon, comment pouvez-vous rationaliser les utiliser dans certains endroits mais pas dans d'autres? En outre, s'il y a déjà un changement de la manière dont les getters sont mis en œuvre, vous pourriez vous retrouver avec des sacs subtils. Tostring () fait partie de la mise en œuvre, il devrait également être cohérent.
En termes de performance, cela ne devrait pas avoir d'importance - vos getters and Setters and Setters devraient être des méthodes finales de toute façon, elles devraient donc être inlinées de toute façon. S'ils ne sont pas finaux, vous devriez vous demander pourquoi et éviter d'accéder directement aux champs directement à moins que ce soit vraiment ce que vous voulez faire.
C'est plutôt subjectif, peut-être un wiki communautaire?
S'il y a une raison fonctionnelle de préférer l'un sur l'autre, ce n'est pas subjectif.
Oui, il y a une raison fonctionnelle de préférer les getters. Si vous utilisez une orj avec une initialisation paresseuse, utiliser les champs directement ne fonctionnera pas. ont été mordu par ce bogue avant, + toujours + utilisez des getters en entités.