Tableaux d'objet en Java

Bonjour,

J'ai créé et déclaré un tableau de la façon suivante :
Essai[] lesEmpruntsEnCours = new Essai[nbEmpruntsEnCours]

puis je cherche à construire chaque élément de mon tableau :
for(int i = 0; i < nbEmpruntsEnCours; i ++)
{
lesEmpruntsEnCours[i]= ???????;
}
et je ne sais pas quoi mettre dans cette construction : tout ce que j'ai essayé ne marche pas.
Merci d'avance pour vos réponses.

Bonjour,

C'est un tableau de type Essai[], il ne peut donc contenir que des instances de type Essai :

Code:

---

lesEmpruntsEnCours[i]= new Essai(...);

---

un objet de type "Essai" : "new Essai();" par exemple.

[EDIT] Grilled

Bonjour a toi, Tu veu vraiment travailler avec les tableaux?
Personnellement j'ai déjà fait des collection d'objet comme ça et je préfère utiliser les Vector prototypé. Cela te permet de ne pouvoir y mettre qu'un seul type d'objet.
La déclaration en serait:

Code:

---

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

//déclaration Vector<MONTYPEDOBET> levecteur = new Vector<MONTYPEDOBJET>(); //Boucle d'ajout for (int i=0; i<levecteur.size(); i++) { //Instanciation d'un objet avec tout le traitement pour remplir les != champs MONTYPEDOBJET obj = new MONTYPEDOBJET(...,....,....); levecteur.add(obj); }   //Lecture MONTYPEDOBJET lu=null; for (int i=0; i<levecteur.size(); i++) { //récupération de l'objet mis dans le vecteur lu = (MONTYPEDOBJET)levecteur.elementat(i); }

---

Sinon, je pense qu'en utilisant les tableaux, il te suffirait de faire:

Code:

---

1 2 3 4 5

for(int i = 0; i < nbEmpruntsEnCours; i ++) { lesEmpruntsEnCours[i]= tonobjet; }

---

j'espère t'avoir aider
Moufasa

edit : merdre plus le premier a répondre... :aie:

Citation:

---

Envoyé par moufasa

Personnellement j'ai déjà fait des collection d'objet comme ça et je préfère utiliser les Vector prototypé

---

Ca fait un bail que l'utilisation de "Vector" est déconseillée, au profit des "List" (ArrayList, LinkedList, etc.).

Par ailleurs, en fonction de la problématique, un tableau peut être mieux adapté au besoin (mais là, je ne suis pas devin...).

ha bon? Pourquoi est ce déconseillé?

Parce qu'un Vector est "synchronized", ce qui le rend plus cohérent dans une application multi-threadée, mais du coup, ralentis l'exécution globale.
C'est pour ça qu'en général dans les applications on utilises plutôt ArrayList qui est plus rapide.

De toute façon normalement c'est à toi de t'assurer que des thread concurrents ne vont pas modifier la même variable en même temps (si tu ne comprends rien à ces histoires de synchronized, retiens juste que ArrayList est une classe représentant un tableau, tout comme Vector, mais en plus rapide)

Après tout dépend, si tu n'as pas prévu de déplacer des élements de ton tableau une fois qu'il est crée, un simple tableau est encore plus rapide il me semble.

Citation:

---

Envoyé par we.are.the.storm

C'est un tableau de type Essai[], il ne peut donc contenir que des instances de type Essai :

---

Petite rectification : il ne peut contenir que des instances d'objets qui implémentent ou surchargent Essai... idem pour les listes génériques.

Citation:

---

Petite rectification : il ne peut contenir que des instances d'objets qui implémentent ou surchargent Essai... idem pour les listes génériques.

---

C'est ce que j'appelle "être de type Essai"...

Citation:

---

Envoyé par Jidefix

Parce qu'un Vector est "synchronized", ce qui le rend plus cohérent dans une application multi-threadée, mais du coup, ralentis l'exécution globale.
C'est pour ça qu'en général dans les applications on utilises plutôt ArrayList qui est plus rapide.

De toute façon normalement c'est à toi de t'assurer que des thread concurrents ne vont pas modifier la même variable en même temps (si tu ne comprends rien à ces histoires de synchronized, retiens juste que ArrayList est une classe représentant un tableau, tout comme Vector, mais en plus rapide)

---

Ca ralentit pas tant que ca... les application que j ai déjà développée avec des vecteurs ne sont pas du tout lente. Enfin c est quand même bon à savoir.

Citation:

---

Envoyé par moufasa

Ca ralentit pas tant que ca... les application que j ai déjà développée avec des vecteurs ne sont pas du tout lente. Enfin c est quand même bon à savoir.

---

Vector est lent par rapport à ArrayList, ça reste une classe dont tout le monde se contentait jusqu'à la v1.2 et encore après.
Après j'imagine qu'il faut une appli très intensive pour s'en rendre réellement compte, perso j'ai jamais vérifié (tiens j'essaierai demain si je trouve 5 minutes au boulot pour voir :P )

Citation:

---

Envoyé par Jidefix

Vector est lent par rapport à ArrayList, ça reste une classe dont tout le monde se contentait jusqu'à la v1.2 et encore après.
Après j'imagine qu'il faut une appli très intensive pour s'en rendre réellement compte, perso j'ai jamais vérifié (tiens j'essaierai demain si je trouve 5 minutes au boulot pour voir :P )

---

C'est comme pour les stringbuffer vs stringbuilder. Tu ne sens pas vraiment la différence des synchronized, tant que tu n'utilise pas une architecture multi processeur (j'ai pas dit multi-core). En effet, sur ces architectures, pour garantir l'unicité des lock entre les processeurs, il faut synchroniser les processeurs, généralement via un lock du bus de donnée. Ces opérations sont beacoup plus couteuses que de la synchronisation de thread au sein d'un unique processeur (qui ne fait internvenir là que la logique du load balancer). En pratique, ton application commence à avoir des performance minable le jour ou tu la fait passer d'un mono processeur à un bi processeur (paradoxal :D)

Pour rebondir sur le problème de synchronisation, je préfère les "List" aux "Vector" (pour une question de standardisation), même lorsque la synchronisation est nécessaire : Sun a fourni dans son API un moyen de synchroniser les listes (ainsi que les Map, etc.) qui ne le sont pas par défaut en cas de besoin.

Code:

---

List<T> listeSynchronisee = Collections.synchronizedList(listeNonSynchronisee);

---