Discussion :

[Oberown]

Bonjour,
J'ai une question de modélisation, j'espere être sur le bon sous-forum.

Imaginons qu'on a un match de football
Mes classes sont
- Match
- Equipe
- Joueur

Ma classe Match contient plusieurs équipes donc il possède une liste d'Equipe
Ma classe Equipe contient plusieurs joueurs donc il possède une liste de Joueur

Un Joueur est forcément dans une seule Equipe. Il ne peut être dans aucune équipe

A partir de ma classe Joueur, comment savoir dans quel Equipe il est ?

- Est-ce que je doit rajouter une référence equipe dans mon joueur, mais cela risque d'être contraignant lorsque qu'il change d'équipe où je dois mettre à jour son référencement ?

- Est-ce que je dois créer une fonction dans Equipe qui permet de savoir si un joueur appartient à cette équipe ? Mais je dois parcourir toutes mes équipes et parcourir la liste des joueurs ce qui est long.

- Autre ?

En résumé quand j'ai un contenu comment faire pour savoir son contenant ?

[hed62]

Tout dépend... Généralement j'opte pour la première méthode (le contenu possède une référence au contenant) et les méthodes d'ajout suppression du contenant se chargent de mettre à jour cette référence.

Tu es en UML, Merise, autre ?

[Oberown]

Je ne suis sur aucun modéle (UML, Merise) pour ce cas.

J'essaye de bien architecturer mes classes (je pense que ca se rapproche plus à de l'UML, bien que je n'ai fait aucun schéma)

[elbj]

Bonsoir

Je suis du même avis que hed62 : mettre une référence du contenant dans le contenu.

Maintenant, dans ton modèle, le fait qu'il y ait une "liste" d'équipes pour un match me semble bizarre. N'y a-t-il pas que 2 équipes dans un match ?

Pour la mise à jour il suffit de prévoir les méthodes correspondantes dans Equipe
- AjouterJoueur(Joueur aJoueur)
- RetirerJoueur(Joueur aJoueur)

Et SetEquipe(Equipe aEquipe) dans la classe Joueur.

Dans la méthode AjouterJoueur, juste avant l'ajout à la liste, tu invoques la méthode SetEquipe(this). Dans la méthode RetirerJoueur ce sera SetEquipe(null).

Enfin, dans ton outil de gestion, genre une classe EquipeManager, tu peux avoir une méthode TransfererJoueur(Joueur aJoueur, Equipe aSource, Equipe aDestination) qui se chargera d'invoquer aSource.RetirerJoueur(aJoueur) puis aDestination.AjouterJoueur(aJoueur).

Voilou

Bon courage

Christophe B.

[ndp]

salut,

D'accord aussi.
Conceptuellement tu as une association naviguable dans les deux sens:
Equipe <-> Joueur

C'est clair que niveau code, pouvoir naviguer avec une reference, c'est plus facile. et je rejoint les autres sur ta premiere proposition.

Dans des cas plus complexes, tu n'auras peut etre pas envie de gerer la coherence de tes references en plus de plein d'autre chose. Donc tu pourrais privilegier une direction dans ton association, et la nivaguabilite dans l'autre sens se fera avec ta fonction, et tu pars sur ta seconde proposition.

Pour moi ce qui serait important c'est que conceptuellement tu as une association naviguable entre deux entites

[benito1er]

Salut

je pense que pour ta modélisation tu as commis une petite erreur,
Un Match concerne forcément deux équipes
Une Equipe contient plusieurs joueurs donc il possède une liste de Joueur

Un Joueur est forcément dans une seule Equipe. Il ne peut être dans aucune équipe

soit tu décides de faire une relation bidirectionnelle et dans ce cas tu devras avoir:
- dans un cas 1 un joueur devra être dans maximun une équipe donc, lorqu'il change d'equipe, il y a une mise à jour et on ne pourras pas savoir ses précédentes equipes (et la dates durant laquelle il y a fait parti)
- soit dire qu'un joueur peut etre dans 0 ou plusieurs equipe et dire qu'il y aura autre chose EstDansEquipe qui devra retourner la date debut la date fin l'equipe et le joueur

oui moi aussi je rejoinds les autres, mais n'oublie pa qu'on perd une tracabilité

Cordialement