Bonjour
A quoi sert la méthode toString() concrètement ? Car elle est souvent utilisé mais je ne la comprends pas
merci
Version imprimable
Bonjour
A quoi sert la méthode toString() concrètement ? Car elle est souvent utilisé mais je ne la comprends pas
merci
... À donner une représentation texte de l'objet.
Par exemple, pour aider au débogage, ou pour écrire l'état d'un objet dans les logs...
J'ai pas compris lol
regarde pas exemple ce diagramme de classe :
a quoi sert toString() dans la class Vehicule Pièce jointe 184324 ?
Sachant que la méthode toString est héritée directement de la classe Object, si tu la mets dans un diagramme UML, ça veut dire que tu la surcharge pour lui donner un sens et afficher des informations utiles liées à l'objet
Sinon, ça se contente d'afficher une chaine de caractère par très causante (avec le nom de la classe et un bout de code hexadécimal représentant son hashcode)
Donc ça veut dire que les classes ont une méthode toString()... Qui sert à convertir une instance d'objet dans une forme de chaîne de caractère... Mais on ne peut pas te dire pourquoi ils font ça et quel résultat est attendu avec un diagramme
Ouais enfin, il y a pas à se demander pourquoi ou comment.
Pour un Vehicule dont le nom serait Batmobile de marque RENO, qui coûte 165000 et qui a toutes les options, la méthode toString() a pour but de renvoyer un truc qui ressemble à ça :
Après il y a plus qu'à faire un petit :Code:"Batmobile RENO [GPS, Climatisation, BarreDeToit, SiegeChauffant, VitreElectrique] 165000"
et la console affiche :Code:System.out.println(maBatmobile);
Ce qui est tout de même plus pratique que si on avait fait autrement -_-°.Citation:
Batmobile RENO [GPS, Climatisation, BarreDeToit, SiegeChauffant, VitreElectrique] 165000
D'accord,
en gros ça nous renvoi une représentation des informations de l'objet quoi !
d'ailleurs la méthode toString() est un sujet qui fâche parfois ... effectivement il faut savoir répondre à la question : à quoi ça sert?
- problème 1: méthode toString() avec héritage : on a parfois des problèmes à faire un super sur le toString() de la classe mère si la classe mère "formatte" trop la chaîne (par ex: avec accolades ouvrantes et fermantes ...)
- problème 2: dans certains cas il faut savoir créer une chaîne "reinjectable" dans un constructeur de la classe (je veux dire la chaine générée par toString() peut être utilisée pour reconstituer un objet)
Si tu as des problèmes à ce niveau là, c'est que tu donne à toString un role bien au delà de sa définition, qui est de donner une représentation compréhensible de l'objet et son état, principalement à des fin de debuggage ou de logging. toString n'a nullement besoin de respecter un standard de formattage ni de permettre de reconstituer l'objet. Si t'as besoin de ça, c'est un besoin spécifique à couvrir avec tes propres méthodes :)
Dixit la javadoc
Le résultat doit être concis, informatif et facile à lire par une personne. Ni plus ni moins.Citation:
The result should be a concise but informative representation that is easy for a person to read
oui et non:
problème n°1: on hérite parfois de classes dans lequel toString() a un formattage parenthésé (d'ailleurs les IDE ont la mauvaise habitude de fournir ça par défaut). le rajout d'éléments par la classe fille oblige alors à réécrire complètement le toString()
problème n°2 : effectivement la gestion d'un format texte re-injectable n'entre pas par défaut dans le rôle .... mais est pratique pour des objets valeurs simples (style BigDecimal)
et j'en rajoute un: "facile à lire par une personne" conduit souvent les programmeurs à écrire des codes non-internationalisable.
J'en vois pas la nécessité:
ca te retourne truc genreCode:
1
2
3 public String toString(){ return "(paramX="+paramX+", paramY="+paramY+", "+super.toString()+")"); }
(paramX=2, paramY=3, (paramA=1,paramB=2))
ce qui en plus évite de confondre les attribut du père et du fils.
toString() n'est pas destiné au front user, donc pas besoin d'aller y tapper de l'internationalisation :weird:Citation:
et j'en rajoute un: "facile à lire par une personne" conduit souvent les programmeurs à écrire des codes non-internationalisable.