Discussion :

[lkryss]

Bonjour,

Je cherche à faire le diagramme de classe d'un jeu de puissance 4. J'ai relu mes cours et divers tutos et je cherche à savoir si ce que j'ai commencé à faire est bien ou non. Si vous avez des remarques, des questions ou des suggestions merci de m'en faire part.

[hed62]

Il faudrait pousser un peu plus le DC, pour l'instant on ne peut pas dire grand chose (cardinalités, copositions/aggrégations ...)

Petite suggestion : utilise le pattern observer/observé entre le model et la vue, c'est utile

[ze_corsaire]

J'ai le sentiment que tu es bien parti dans le découpage des responsabilités.
Effectivement, il faut que tu affines tes associations.
UMLment parlant, des relations ne sont pas bonnes, notamment entre interfaces. Ton interface JeuView ne peut réaliser l'interface JeuControler. J'ai d'ailleurs du mal à comprendre ce que tu voulais représenter, soit un héritage entre les interfaces, JeuView délégant tout appel de méthode à sa méthode pendante dans JeuControler ou une relation de dépendance entre les classes qui implémentent respectivement ces interfaces. De même deux interfaces ne peuvent être associées.
Peut-être que de réaliser une vue dynamique en parallèle te permettrait d'y voir plus clair.

[lkryss]

Bonjour, merci pour vos réponses.
En fait mes relations entre mes packages sont la pour représenter le pattern MVC, et sur les exemples que j'ai vu sur la représentation d'un uml MVC cela se représente comme ceci (bon ok visual paradigm est en anglais et je ne suis pas sur de mon uml avec les termes anglais :/). Et la génération de code de VP ne m'indique pas d'erreur dans mon schéma (mais ça ne veut pas dire qu'il est bien pensé).
j'ai utilisé le pattern stratégie pour les niveaux de difficultés. On m'a dit d'utiliser le pattern schéma de méthode mais j'avoue ne pas vraiment comprendre comment appliquer ce dernier.

Peut-être que de réaliser une vue dynamique en parallèle te permettrait d'y voir plus clair.

tu veux dire quoi par la?

pour le pattern observer/observé ce n'est pas le but de MVC ?

[ze_corsaire]

Je ne me focalisais pas sur le MVC.
J'avais dans l'idée de représenter le déroulement d'une partie par exemple de manière à te rendre compte des classes/méthodes/cardinalités manquantes ...

[ndp]

Salut

...
j'ai utilisé le pattern stratégie pour les niveaux de difficultés. On m'a dit d'utiliser le pattern schéma de méthode mais j'avoue ne pas vraiment comprendre comment appliquer ce dernier...

Moi je te conseillerai d'attendre un peu pour les niveaux de difficultes, a moins que tu saches des maintenant comment les niveaux de difficultes font affecter le comportement de ton appli.
Une fois que tu sauras quelle partie de code va varier selon le niveau de difficulte, tu pourras par exemple, choisir entre:
DP Strategy: remplacement complet d'algorithmes
DP Template Method: seule certaine partie d'un algo varie

...
pour le pattern observer/observé ce n'est pas le but de MVC ?

je pense que MVC c'est plus "separation of concerns" alors que Observer/Observable c'est plus du "loose coupling", dsl pour le melange anglais/francais

[lkryss]

Déroulement d'une partie :

1-JeuControlleur demande la création d'un puissance4 (initialisePartie) qui passera par JeuView afin de dessiner mon plateau de jeu vide (DessineTableau), et donne à JeuModel le niveau de difficulté choisit.

2-Jeu controller va ensuite attendre la selection d'une case par le joueur (la je me dis que FaireJouer va plutôt dans mon interface joueur non? car cela declencherait un SetStratégie mais pour le joueur)

3- une fois que le joueur a joué JeuController réactualise le tableau de jeu en mémoire (je pensais faire cela dans FaireJouer mais c'est peut être plus clair si j'ajoute une méthode ActualiserValeursTableau dans JeuModel vu que c'est lui qui est sensé faire les modifications) et il va demander à JeuView d'actualiser l'affichage du tableau : ActualiseAffichageTableau.

4-ensuite JeuController regarde si on arrive à un tableau qui rempli les conditions d'une partie finie (PartieTerminee) si ce n'est pas le cas il passe à l'ordinateur(FaireJouer) qui appelle JeuModel pour faire calculer la stratégie de la machine. Puis comme dans 3 : réactualisation du tableau en mémoire et à l'affichage. puis retour au point 2.

En me lisant j'ai l'impression que je vais devoir créer des classes quasiement vide qui n'auront pour intêret que d'appeller d'autres classes situés dans d'autres paquets, mais je pense que je n'en vosi pas l'intêret car le jeu est trop simple (enfin c'est une remarque perso).

En ce qui concerne le changement de stratégie, oui je sais commetn mon algo va varier, c'est un simple alpha-beta donc seule la profondeur de recherche sera modifiée. Je pense que ma conception à ce niveau la est correct.