Bonjour à tous,

Je suis entrain de traiter un exercice en Java, où les objectifs sont en résumé de gérer une population. Après avoir créé une classe Humain (abstraite), une classe Homme et une classe Femme (ainsi que tous les attributs/méthodes nécessaires), il met demandé de déclarer et d'instancier une variable Vector Population. Seulement, malgré une lecture de l'API Java, j'ai un peu de mal à comprendre comment Vector marche avec les objets...

Pour plus de précision, le constructeur d'Homme est le suivant :
public Homme(String nom,int age, int poids, int esperanceVie)

Et la consigne à respecter est :
- d'instancier tailleInit/2 Homme et tailleInit/2 Femme, en les insérant dans population;
- utilisez le constructeur qui permet de fixer la valeur de tous les attributs en prenant comme valeur : age = 20 pour homme et 25 pour femme, etc.

Sans l'utilisation de Vector, il me suffirait donc d'un simple :
Homme h1 = new Homme("John",20,70,70);
Mais comme il faut absolument que j'utilise Vector...

Bref, un coup de main sur ce coup là serait vraiment sympa, et merci d'avance si vous prenez le temps de me répondre !

Je sais pas si t'as vu la généricité mais visiblement tu vas en avoir besoin.
Si j'ai bien compris l'énoncé la déclaration de ton vector devrait ressembler à :
Vector<Humain> population = new Vector<Humain>();
...que tu remplirais ensuite avec la méthode d'ajout en passant des hommes et des femmes en paramètre...

Si tu es en train d'apprendre le Java, tu dois utiliser la version 6 je pense.
Dans ce cas, à moins que la personne qui t'a donné cette exercice y tient absolument, n'utilises pas un Vector, mais plutôt les listes, ça te simplifiera déjà la vie.

Sinon, pour ta question, tu n'as absolument pas besoin de la généricité, juste d'un :

Vector population= new Vector(); // création du vecteur
population.add(unHomme); // ajout d'un homme "unHomme" dans le vecteur

Il n'y a rien d'autres à faire pour utiliser (sommairement) un Vector (ou à peu près n'importe quel conteneur en fait ...).

Je me mange des warnings si je précise pas le type du Vector. Alors effectivement c'est pas absolument nécessaire, mais c'est mieux.

Ok, donc tu utilises bien une version 1.4 ou supérieure.
Dans ces versions, il est fortement conseillé de "générifier" ses propre conteneurs et d'utiliser les types générique sur les conteneurs de la librairie de base.

Tu vois à quoi servent les types génériques ou pas ? (à part te virer des warning, cela va sans dire)

Merci à String[]args (joli pseudo au passage ) et Bunyan pour vos réponses !

Effectivement, je n'avais pas encore vu la généricité, merci pour la découverte, et même si tous n'est pas encore clair, cela me sera surement utile ! Et oui, nous utilisons la version 6 à l'université et l'utilisation des Vector n'est pas obligatoire, la consigne de l'exercice nous aiguille juste là dessus...

J'ai encore plusieurs questions, peut-être un peu bête... Voici mon main actuel :

public static void main(String[] args){
Vector<Object> population = new Vector<Object>();

//constructeur d'Homme : public Homme(String nom)
population.add(new Homme("Bill"));
population.add(new Homme("John"));

//juste un test...
for (Object o : population){
System.out.println(o);
}
//retourne Homme@c17164 et Homme@1fb8ee3
}

Je vois mal comment faire pour appeler ensuite les méthodes de la classe Homme... Avant, un simple 'h1.print();' appelait la méthode print (qui donne la valeur de certains attributs dans mon cas). Est-il possible, en utilisant les Vector, d'appeler cette méthode, pour l'homme "John" par exemple ?

Déclare ton vecteur comme un Vector<Humain>, parce que t'iras pas loin avec un vecteur d'Object. T'as une classe abstraite qui est parfaite pour faire ce genre de collection hétérogène : ton vecteur pourra stocker des Homme, des Femme et appellera la méthode correspondante selon le type de l'objet du vecteur actuel !

Comme ça tu pourras parcourir ton vecteur avec par exemple :
for(Humain h : population) h.print();
Et t'auras des sorties du genre "Je suis John !" ou "Je suis une femme !".

Je comprend bien mieux pourquoi on a du revoir brièvement les notions d'héritages et de classes abstraites, malin le prof' !

Merci pour le coup de main en tout cas, j'ai les idées un peu (beaucoup même !) plus claires maintenant et je ne devrai pas trop avoir de mal à finir l'exercice.

En espérant te rendre la pareil un jour (sait-on jamais ! ),
bon week-end !

Sans la généricité bien utilisée, pour appeler tes méthodes de l'objet humain sur les objets de ton Vector, tu devrais faire :

Object objet = population.get(i);
if (objet instanceof Humain)
{
Humain humain = (Humain)objet;
humain.maMethode;
// ou on peut faire : ((Humain)objet).maMethode; à la place des deux lignes
}

Concernant ta première utilisation en "Vector<Object>", c'est exactement comme si tu écrivais "Vector" en fait. La syntaxe change, mais le sens en est exactement le même.

En utilisant bien, comme l'écris String[]args, "Vector<Humain>". Avec ceci, ton vector contient normalement uniquement des objets de type Humain, donc tu n'auras pas à passer par le test du type et le transtypage.

Concernant le "for" que String[]args utilise, je pense que tu l'as déjà vu, mais c'est un "for each", qui est disponible en Java depuis la version 1.5. C'est un simple sucre syntaxique pour éviter d'écrire toujours le même code de parcours de collection via un itérateur (bien que cette méthode là soit toujours aussi valable, et est même à privilégier dans certains cas).

Concernant ce genre de retour : "Homme@1fb8ee3 ". C'est le retour standard de la méthode toString(), qui est appelée par défaut lors d'un affichage quelconque. Cela représente le type de l'objet, puis son adresse. Pour avoir un p'tit truc qui va bien, redéfinir toString() dans ses objets (mais je pense que ce paragraphe fait aussi doublon).

L'exercice qui sent le prof qui confond un vector au sens java et un vector au sens STL. Vector est une collection thread safe obsolète, un arraylist serait plus indiqué.

Merci pour ces précisions Bunyan ! J'ai suivi ton bout de code pour finir l'exercice, car il est assez simple à adapter pour ma situation (j'ai, entre autres, une méthode où je dois faire rencontre des Humain entre eux).

Je m'aperçois avec le recul de mon erreur concernant Vector<Object>, c'est vraiment le genre de "faute" de débutant ! Juste, si en utilisant Vector<Humain> je m'assure qu'il n'y est que des Humain dans mon Vector, pourquoi dois-je vérifier si objet est bien une instance d'Humain dans le code que tu m'as donné ?

Et pour les petits paragraphes que tu as rajouté, c'est le genre d'explication que j'aime vraiment, qui renforce les choses qui ne sont pas encore tout à fait sures, qui ont été vu trop rapidement en cours... Bref, merci du temps que tu as pris !

_skip, je ne sais pas trop quoi te dire, si ce n'est que c'est seulement temporaire, et que durant les prochains TP, on devrait gérer notre population "avec une classe Population, qui utilisera les classes de collection avancées de Java".

_skip, pourquoi vector est il obsolete?

Tu veux juste dire que la plupart du temps, arraylist est preferable a vector (pour ne pas payer l'overhead du moniteur). Ou est ce que vector ne devrait etre utiliser dans aucun cas?

Mon bout de code est, comme je l'ai indiqué au-dessus, dans le cas de la non-utilisation de la généricité, ou une mauvaise utilisation.
Donc, dans le cas d'utilisation d'un Vector simple, ou d'un Vector<Object>.

@Godrik

Vector est synchronisé et lock à chaque appel. Cela fait longtemps en fait que son utilisation est découragée.

La façon moderne de faire la même chose est d'utiliser une collection ordinaire (qui ne lock pas) et de créer un wrapper qui s'occupe de la synchronisation :

http://download.oracle.com/javase/6/docs/api/java/util/Collections.html#synchronizedCollection%28java.util.Collection%29

Ca a l'avantage de permettre de laisser le développeur décider si la synchro est nécessaire ou non suivant le contexte d'utilisation. Si au démarrage de ton application tu veux populer une liste à partir d'un fichier pour en faire un cache ou je ne sais quoi, tu peux la charger en non synchronisé, puis la passer en synchronisé plus tard grâce au wrapper lorsque cela devient nécessaire.