Discussion :

[mariemor64]

Comment est-il possible de savoir à quel indice on se situe dans un Vector?

[Yoops]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int position = vecteur.indexOf(tonObjet);

Les objets seront comparés grâve à la methode Object.equals(), il te sera peut être nécessaire de la surcharger.

[mariemor64]

J'ai fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int position = vecteur.indexOf(tonObjet);

mais je ne comprends pas pourquoi ça me renvoit -1

[®om]

J'ai fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int position = vecteur.indexOf(tonObjet);

mais je ne comprends pas pourquoi ça me renvoit -1

Peut-être parce que "tonObjet" n'est pas dans le vecteur

Et au fait, pourquoi vous utilisez des Vector et pas des ArrayList?

[mariemor64]

Je sais que je devrais utiliser des ArrayList mais là j'ai 20 classes et un 10aine de jsp avec des vecteurs alors ça attendra pour tt modifier.

Certes mon objet n'est pas dedans, je m'en suis aperçu...

Mais mon problème se complique : je voudrais savoir un objet dont un attribut a une certaine valeur est dans mon vecteur

[®om]

Je sais que je devrais utiliser des ArrayList mais là j'ai 20 classes et un 10aine de jsp avec des vecteurs alors ça attendra pour tt modifier.

Certes mon objet n'est pas dedans, je m'en suis aperçu...

Mais mon problème se complique : je voudrais savoir un objet dont un attribut a une certaine valeur est dans mon vecteur

Soit tu parcours ton vecteur et tu testes l'attribut, soit (si au niveau du sens c'est correct) cet attribut est vraiment lié à la notion d'égalité de ton objet, et dans ce cas tu redéfinis la méthode equals...

[mavina]

Salut,

Il convient d'expliquer un peu cette fonction hashCode() si importante :

La complexité d'accès à une valeur par sa clé (meme principe que le indexof() ) dépend d'une fonction appelée hashCode définie dans la clé. Cette fonction est déjà définie dans Object, mais pour optimiser la recherche, la surcharger dans vos propres classes (si la clé est une instance d'une classe de votre création) permet un gain de temps non négligeable. Le principe de cette fonction est simple : elle renvoie un entier. Si les deux objets sont égaux, les valeurs renvoyées par leur fonction respectives sont égales, mais l'inverse n'est pas vrai, ce qui veut dire que si deux objets sont inégaux, leurs hashCode ne sont pas forcément inégaux.
Généralement, on fait renvoyer à la fonction hashCode() d'un objet la somme des hashCode() des éléments le composant.

^^

mavina

[mariemor64]

Merci pour la surcharge de la méthode equals() et hashcode().

J'ai tout de même toujours un problème

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
for (int i = 0; i < getResults().size(); i++) {
            Object o = getResults().get(i);
            if (o.equals(pFacade)) {
                position = i;
            }
            i++;
        }

Mon objet o ne semble pas exister alors que mon vecteur n'est pas vide (j'ai testé la taille)

[mavina]

Salut,

Il faut caster l'objet (ou utiliser la nouvelle boucle, au choix) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
for (int i = 0; i < getResults().size(); i++) {
            MonType current = (MonType)getResults().get(i);
            if (current.equals(pFacade)) {
                position = i;
            }
            i++;
        }

nouvelle boucle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
for(MonType current : getResults())
{
  if(current.equals(pFacede))
  {
    pisition=getResults.indexOf(current);
  }
}

voila voila ^^

edit : si tu as un peu de mal a prendre en main les collections, visite mes publications (dans ma signature).

mavina

[mariemor64]

J'avais déjà essayé en castant mon objet mais ça ne marche pas nom plus...

Sinon je ne comprends pas elle marche

[@ldehan]

Merci pour la surcharge de la méthode equals() et hashcode().

J'ai tout de même toujours un problème

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
for (int i = 0; i < getResults().size(); i++) {
            Object o = getResults().get(i);
            if (o.equals(pFacade)) {
                position = i;
            }
            i++;
        }

Mon objet o ne semble pas exister alors que mon vecteur n'est pas vide (j'ai testé la taille)

c'est normal que tu fasse 2 fois i++ ?
tu parcours de 2 en 2 tes elements...

[®om]

La complexité d'accès à une valeur par sa clé (meme principe que le indexof() ) dépend d'une fonction appelée hashCode définie dans la clé. Cette fonction est déjà définie dans Object, mais pour optimiser la recherche, la surcharger dans vos propres classes (si la clé est une instance d'une classe de votre création) permet un gain de temps non négligeable. Le principe de cette fonction est simple : elle renvoie un entier. Si les deux objets sont égaux, les valeurs renvoyées par leur fonction respectives sont égales, mais l'inverse n'est pas vrai, ce qui veut dire que si deux objets sont inégaux, leurs hashCode ne sont pas forcément inégaux.
Généralement, on fait renvoyer à la fonction hashCode() d'un objet la somme des hashCode() des éléments le composant.

Je ne suis pas tout à fait d'accord...
Déjà sur le fait de surcharger hashCode() (à part pour renvoyer par exemple un monString.hashCode) doit impliquer coder une fonction de hashage "bien équilibrée" (et ça ça n'est pas toujours facile).
Et sinon, fire la somme des hashCode() des objets le composant, tu risques de dépasser la taille d'un entier (2^32)... Suffit qu'un des hashCode() donne déjà 0xffe358ad oar exemple et un autre 0xfe6423e8da, tu dépasses 2^32

[mavina]

les fonctions hashcode des objets de l'API sont déja définies, il suffit de bien redéfinir hashcode dans tes classes et sous classes ...

[g_rare]

D'accord avec ®om : ne REdévelopper le "hashCode" que si nécessaire (le risque de collision par programmation foireuse ne compense pas <<à mon avis>> un hypothétique gain de performance), c'est-à-dire dans le cas d'un attribut identifiant seul la valeur d'une instance de classe (et prendre justement son "hashCode" s'il n'est pas déjà numérique).

[adiGuba]

Salut,

D'accord avec ®om : ne REdévelopper le "hashCode" que si nécessaire (le risque de collision par programmation foireuse ne compense pas <<à mon avis>> un hypothétique gain de performance), c'est-à-dire dans le cas d'un attribut identifiant seul la valeur d'une instance de classe (et prendre justement son "hashCode" s'il n'est pas déjà numérique).

Attention toutefois, la méthode hashCode() hérité de Object n'est pas "correcte" dans le sens où elle renvoit une valeur différente pour chaque référence d'objet. Ainsi deux objets strictement identique d'un point de vue logique auront un hashCode différent...

Donc si on veut utiliser ce type d'objet en tant que clef dans une Map, il faut redéfinir hashCode() (a moins d'hériter d'une classe qui le fait déjà).

Déjà sur le fait de surcharger hashCode() (à part pour renvoyer par exemple un monString.hashCode) doit impliquer coder une fonction de hashage "bien équilibrée" (et ça ça n'est pas toujours facile).

Pour cela, on peut utiliser les Jakarta Commons Lang qui propose des "builder" pour générer simplement des hashcodes...

Et sinon, fire la somme des hashCode() des objets le composant, tu risques de dépasser la taille d'un entier (2^32)... Suffit qu'un des hashCode() donne déjà 0xffe358ad oar exemple et un autre 0xfe6423e8da, tu dépasses 2^32

Je ne pense pas que cela pose un gros problème. Tu te retrouvera simplement avec un hashcode négatif...

a++