Afficher liste d'objets et leur éléments avec ArrayList

Bonjour, je veux créer une liste d'objets de type Animaux.

J'ai réussi à créer cette liste , mais je n'arrive pas à afficher les résultats comme je le souhaite.
C'est bien les objets qui s'affichent mais moi je voudrais leurs caractèristiques.

Voici mon résultat:
Araignee@56815616
Dauphin@33587363
Lyon@83336362

Alors que je voudrais un truc du genre

Araignée 8 Pattes 30 grammes
Dauphin 150 kgs bleu
Lyon 4 pattes 120 kgs jaune

voici mon code d'affichage (je comprends pourquoi l'objet s'affiche, mais je ne vois pas comment afficher ses attributs)

Code:

---

1 2 3 4

for(int i = 0; i < ListeAnimaux.size(); i++) { System.out.println("donnée à l'indice " + i + " = " + ListeAnimaux.get(i)); }

---

bonjour,

si ta liste contient les objets de type Animal et que la classe Animal dispose des getters (nom, poids,...) tu peux afficher chaque objet de la liste en faisant appel à ses getters

Code:

---

1 2 3

for( Animal a : ListeAnimaux) System.out.println(a.getNom() +"\t"+ a.getPoids());

---

Autre possibilité:
Redéfinir dans la classe Animal, la méthode toString qui retournerait les caractéristiques(pois, nom..) de l'animal ce qui te permettra pendant le parcours de la lsite d'afficher des objets(comme tu l'as fait).

Salut,

Lorsqu'on affiche un objet, par un System.out.println( object );, c'est sa méthode toString() qui est appelée pour déterminer la chaîne à afficher (C'est comme si tu écrivais System.out.println( object==null ? "null" : object.toString() );.

Donc tu dois implémenter cette méthode sur tes classes, de manière à ce qu'elle renvoit la chaîne que tu désires, en la construisant en assemblant les différentes parties. Si tu n'as qu'une partie (une seule variable par exemple), la retourner si c'est du String, ou la convertir avec String.valueOf(). Le moyen le plus direct étant la concaténation, mais il vaut mieux préférer l'utilisation d'un StringBuilder dès que tu as plus de 2 parties (c'est de toute manière ce qui est utilisé quand tu fais de la concaténation), pour économiser en temps d'exécution et mémoire.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public class Personne {   private String nom; private String prenom;     public Personne(String nom, String prenom) { this.nom=nom; this.prenom=prenom; }   public String toString() { StringBuilder stringBuilder = new StringBuilder(); stringBuilder.append(nom); stringBuilder.append(" "); stringBuilder.append(prenom); return stringBuilder.toString(); }     }

---

Si tu as une hiérarchie de classes, tu pourras éventuellement :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public abstract class Animals{   private String nom;     public Personne(String nom) { this.nom=nom; }   public final String toString() { StringBuilder stringBuilder = new StringBuilder(); toString(stringBuilder); return stringBuilder.toString(); }   protected void toString(StringBuilder stringbuilder ) { stringBuilder.append("Nom = "); stringBuilder.append(nom); }   }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class Araignee extends Animals{   private String nom; private int nbPattes   public Araignee(String nom, int nbPattes) { super(nom); this.nbPattes= nbPattes; }   protected void toString(StringBuilder stringbuilder ) { super.toString(stringBuilder); stringBuilder.append(", nb pattes = "); stringBuilder.append( nbPattes ); }   }

---

Merci à vous,

j'ai bien reussi à afficher la liste en utilisant les getters.
Demain je tente la même chose avec les tostring pour vérifier que j'ai bien tout assimiler.

Encore Merci, j'apprécie grandement votre aide.

Citation:

---

Envoyé par joel.drigo

il vaut mieux préférer l'utilisation d'un StringBuilder dès que tu as plus de 2 parties (c'est de toute manière ce qui est utilisé quand tu fais de la concaténation), pour économiser en temps d'exécution et mémoire.

---

Je trouve cette phrase auto-contradictoire. Vu que la concaténation utilise StringBuilder, je ne vois pas personellement de nécessité à les utiliser explicitement. Ceci est plus rapide à tapper, plus facile à lire et a les mêmes performances:

Code:

---

1 2 3

public String toString() { return nom+" "+prenom; }

---

Citation:

---

Envoyé par tchize_

Je trouve cette phrase auto-contradictoire. Vu que la concaténation utilise StringBuilder, je ne vois pas personellement de nécessité à les utiliser explicitement. Ceci est plus rapide à tapper, plus facile à lire et a les mêmes performances:

Code:

---

1 2 3

public String toString() { return nom+" "+prenom; }

---

---

[EDIT]Peut-être aurais-je dû écrire "Lorsque le nombre de parties de la String est fini, et qu'il ne s'agit que d'une suite de ces parties, sans variation, on peut utiliser la concaténation. En cas de construction dynamique, avec de nombreuses parties, pour peu qu'il faille faire des boucles, des options, etc, utiliser un StringBuilder sera préférable....

Sauf que c'est une arborescence (dont on ne connait pas la profondeur) :

Code:

---

1 2 3

public String toString() { return super.toString() + machin + " " + truc... }

---

Je trouve que dans le cas de l'utilisation général, un StringBuilder permet plus de souplesse, genre :

Code:

---

1 2 3 4 5

stringBuider.append( machin ) ; if( expression ) { string.append( truc ); } ...

---

En plus si tu as beaucoup de propriétés (on n'en sait rien non plus), je ne trouve pas que ça soit plus facile à lire...

C'est sûr que pour un cas de base (l'exemple Personne était pour l'exemple), autant utiliser la concaténation. Dans le cas général, personnellement, je préfère utiliser un StringBuilder.

Sans parler de ce cas :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public abstract class Animaux {   private String nom;   public Animaux(String nom) { this.nom=nom; }   public final String toString() { StringBuilder stringBuilder = new StringBuilder(); stringBuilder.append( "[" ); toString(stringBuilder); stringBuilder.append( "]" ); return stringBuilder.toString(); }   protected void toString(StringBuilder stringbuilder ) { stringBuilder.append("Nom = "); stringBuilder.append(nom); }   }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class Araignee extends Animaux{   private String nom; private int nbPattes   public Araignee(String nom, int nbPattes) { super(nom); this.nbPattes= nbPattes; }   protected void toString(StringBuilder stringbuilder ) { super.toString(stringBuilder); stringBuilder.append(", nb pattes = "); stringBuilder.append( nbPattes ); }   }

---

Citation:

---

Envoyé par tchize_

Je trouve cette phrase auto-contradictoire. Vu que la concaténation utilise StringBuilder, je ne vois pas personellement de nécessité à les utiliser explicitement. Ceci est plus rapide à tapper, plus facile à lire et a les mêmes performances:

Code:

---

1 2 3

public String toString() { return nom+" "+prenom; }

---

---

Il est conseillé d'utiliser StringBuilder pour la concaténation au lieu du caractère "+", car il va y avoir création d'un nouvel objet StringBuilder à chaque fois que le "+" est appelé. (Enfin, il me semble)

Pour répondre au topic, lorsque ça t'affiche Araignee@56815616, c'est parce que ça utilise la méthode toString par défaut, celle de Object. Et cette dernière revoie l'adresse mémoire de ton objet. Comme dit plus haut, il faut surcharger cette méthode.

Non, ça n'utilise bien qu'un seul StringBuilder (et encore, s'il n'y avait que des constantes dans la concaténation, même pas). Clairement pour un cas aussi simple, dans le cas isolé, une concaténation vaut mieux. Je voulais juste dire que pour le cas général (et aussi parce que, comme je vois que la concaténation est utilisée tout le temps, y compris quand il ne faudrait pas comme dans String s=""; if ( expression ) s+="xxxx"), ou pour des messages avec beaucoup concaténations, genre "Creating " + newText.getType() + ": can't export text from page to missing property " + key.getPath() + " (Field: " + key.getName() + ")" qui deviennent déjà un peu moins lisble à mon sens (bon, j'aurais tendance à utiliser plutôt un String.format() du coup, dans ce cas, surtout que l'exemple est tiré d'une génération de message de log)), je préférais directement donner un exemple avec StringBuilder (sans écrire 40 lignes de code non plus pour qu'il soit incontestablement justifié) : mais, je l'admets la méthode String de la classe Personne donnée en exemple ne justifie pas l'utilisation d'un StringBuilder explicite.

Citation:

---

Envoyé par joel.drigo

Non, ça n'utilise bien qu'un seul StringBuilder (et encore, s'il n'y avait que des constantes dans la concaténation, même pas). Clairement pour un cas aussi simple, dans le cas isolé, une concaténation vaut mieux. Je voulais juste dire que pour le cas général (et aussi parce que, comme je vois que la concaténation est utilisée tout le temps, y compris quand il ne faudrait pas comme dans String s=""; if ( expression ) s+="xxxx"), ou pour des messages avec beaucoup concaténations, genre "Creating " + newText.getType() + ": can't export text from page to missing property " + key.getPath() + " (Field: " + key.getName() + ")" qui deviennent déjà un peu moins lisble à mon sens (bon, j'aurais tendance à utiliser plutôt un String.format() du coup, dans ce cas, surtout que l'exemple est tiré d'une génération de message de log)), je préférais directement donner un exemple avec StringBuilder (sans écrire 40 lignes de code non plus pour qu'il soit incontestablement justifié) : mais, je l'admets la méthode String de la classe Personne donnée en exemple ne justifie pas l'utilisation d'un StringBuilder explicite.

---

Je suis désolé d'insister (et ce n'est peut-être pas l'endroit pour ce genre de débat ;)) mais il me semble bien qu'il y a création d'un nouvel objet StringBuilder à chaque rencontre avec le signe +. Cet article le confirme d'ailleurs. De plus, il met en exergue du temps d’exécution en plus en utilisant le signe '+'.
C'est pourquoi je me permet de vous contredire, sans animosité aucune bien sûr :P

L'exemple cité a justement séparé le + en deux instructions. Tant que tes concaténations restent dans la même instruction (pas de ; en gros), le compilateur est assez malin que pour ne mettre qu'un seul StringBuilder.

Bref il y a un différence entre :

Code:

---

1 2	String result = 'const1' + base; result = result + 'const2';

---

pas bien! Et

Code:

---

String result = 'const1' + base + 'const2';

---

Mieux :)

C'était peut-être le cas dans d'ancienne version de Java (je me souviens avoir fait des tests comparatifs effectivement qui justifiait l'utilisation d'un StringBuilder au lieu d'une concaténation, mais je ne suis plus sûr dans quelle version (la 1.4 je pense)). Pour avoir fait des tests plus récemment (en java 7), je n'ai plus constaté de réelle différence (et il me semble bien que c'est ce qu'on peut remarquer sur les graphes). Bien sûr, je ne suis pas allé voir le bytecode

Maintenant, en faisant le test en debug en Java 8, on ne voit qu'une seule instanciation d'un seul StringBuilder, avec des appels de append() ensuite. Evidemment, ça dépend du compilateur (et c'est ce que dit cet article). L'utilisation du constructeur avec argument peut avoir son effet : d'ailleurs, personnellement, j'utilise plutôt le constructeur avec taille, que celui avec String, en faisant une estimation de la taille de la chaîne, quand elle n'est pas trop complexe.

Je n'avais même pas regardé le code qu'ils testaient, @Tchize_. Bien vu, ou presque : on s’aperçoit que le code ne compile pas ;) (des ' au lieu de ")

Hmm, très bien. Vos arguments sont recevables. Et bien disons que nous avons tous raison ^^

À noter que les JLS disent spécifiquement que :
- Le résultat d'une opération de concaténation par l'opérateur +, doit être une nouvelle String.
- En cas de concaténations répétées dans une expression, les implémentations ont le droit de se reposer sur des mécanismes comme StringBuffer ou similaires (donc StringBuilder) pour éviter de créer des objets String intermédiaires superflus.

Concrètement il en ressort que si le calcul est composé de plus d'une expression dans le code source, alors l'optimisation en question n'a pas été autorisée par les JLS, et une nouvelle String doit être créée pour chaque expression distincte.

(Je trouve tout de même cela un peu littéral.)

Il y a un autre argument contre l'utilisation direct des StringBuilder quand ce n'est pas indispensable, au passage.

On suggérait pas mal avant l'apparition de StringBuilder, l'utilisation de StringBuffer. Le dialogue était exactement le même: éviter les Strings inutiles, la création d'objets inutiles.

Résultat, à l'apparition de StringBuilder, les codes utilisant StringBuffer qui n'avaient pas été remaniés pour utiliser StringBuilder étaient devenus moins performant que les code utilisant une simple concaténation et ayant été juste recompilé. Ca a été une mauvaise surprise pour pas mal de dev, de voir que leur code "super optimisé" était devenu plus lent que du code "à la con avec juste des +" ;)

Donc par expérience, là où on peut laisser de la marge d'optimisation à la JVM / compilateur plutôt que de le faire nous même, autant la laisser faire, elle fera peut être encore mieux dans 2, 3 , 5 ans :D

On en reviens à un moto de base: n'optimisez pas ce qui n'en a pas besoin ;)

Je n'entrerai pas dans ce débat. Mais merci à tous ceux qui ont répondu, j'ai obtenu le résultat que je souhaitais.;)