Bonjour à tous,
 
J'avais une question à vous poser. Je me suis mis au Java depuis peu et j'ai comme projet de créer un programme de gestion de tournois. Ma question est de savoir si j'ai bien aménagé les choses avant d'aller plus loin. Voici en résumé mon architecture :
 
Class Team : Comporte un String du nom de la team et divers int et boolean permettant de gérer principalement les statistiques (matchs gagnés/perdu et les points)
 
Class Match : Comporte 2 objets de class Team ainsi que divers int et boolean : le numéro du terrain et score principalement
 
Class GroupStage : Comporte un tableau 2D d'objets de class Match ( Match[][] ), permet de générer les matchs de poule avec pour indice 1 le numéro du match (donc le terrain attribué) et l'indice deux le numéro du tour de poule. En fait, son constructeur admet une collections de Team en paramètre et l'objet créer est un tableau 2D de Match. Au début j'ai hésité à en faire simplement une méthode dans ma classe principale qui permettait de générer un tableau 2D de Match grâce à la collection de Team mais j'en ai finalement fait une class, était-ce un bon choix selon vous?
 
Voilà pour mon architecture. Mon souci est le suivant : je n'ai rien fait hérité par "extends" mes class entre elles. La raison est que les class utilisent les autres classes mais on ne peut pas dire "un match est une équipe" ni un "tour de poule est un match". En gros, je réutilise mes class tels quels dans les autres class, j'espère que vous je m'exprime bien. Mon souci là dedans c'est que j'ai toutes mes méthodes "public" et mes variables (attributs) en "protected". Ce qui me pose un problème, c'est qu'une variable protected devrait être visible uniquement dans la class elle-même ou ses classes filles, mais j'arrive très bien à utiliser les variables des Team que je gère dans un Match sans accesseur ni rien (en protected, en private je ne peux pas). Cependant, Team n'est pas une superclass de Match mais j'ai tout de même accès à ses attributs protected...
 
Enfin, tout cela pour vous dire que j'ai un doute sur mon architecture actuelle et avant d'aller plus loin, j'aimerais me rassurer de partir dans la bonne direction.
 
Merci d'avance.

Remarque : normalement tous les attributs en private avec getter et setter. Mais pour un projet perso on peut oublier ... à moins que tu ne veuilles faire un prototype "dans les règles de l'art".
 
Pour le reste : oui cela a l'air bon. En tous cas tu as fait des choix et tu as l'air de les maitriser, donc tu vas y arriver ... il n'y a pas obligatoirement de meilleur choix, l'important être convaincu par les options prises.
 
Ah oui : quelles classes gèrent les actions entre les classes ?

Merci beaucoup pour ta réponse. Ok, je vais les mettre en private et faire des méthodes get et set pour pouvoir y accéder, ça sera plus propre. Oui il me faut y faire des les règles de l'art, j'y fais pour moi en ce moment mais le but est que j'apprenne le Java (ça fait une semaine que je suis dessus environ) pour un futur emploi où je devrais faire des applications pour smartphone qui communique avec d'autres appareils (p. ex. une montre connectée qui mesurerait certains paramètres vitaux et les mesures seront traitées et affiché sur smartphone), donc autant prendre les bonnes habitudes directement.
 
Alors pour les actions entre les class, je vais te donner un exemple :
 
Je crée des objets Team. Ensuite je veux en faire jouer 2 entre elles. Je crée un objet Match m1 = new Match(Team tA, Team tB) ; par exemple.
 
Ensuite le constructeur va initialiser les variables Team de m1 avec les équipes que je lui ai données et va attribuer un terrain en fonction du nombre de match créer et du nombre d'équipe enregistrée au tournoi. L'initiation se fait sans "new" dans le constructeur :
 
teamA = tA ;
teamB = tB ;
 
Dans ma class Match, j'ai une méthode "result" qui permet de donner les scores une fois le match terminé et c'est là que j'ai peur sur l'encapsulation. En gros, suivant le score, j'incrémente le nombre de match gagné à l'équipe, les statistiques de score (points marqué, reçu, moyenne etc). J'utilise les objets Team que j'ai référencé dans mon constructeur et incrémente directement leur attribut. Donc une ligne de code pour incrémenter le nombre de matchs gagné dans ma méthode result de la class Match s'écrit :
 
TeamA.gameWon++ ;
 
gameWon est déclarée protected dans la class Team, pour ça que ça fonctionne. Si j'y mets en private, je devrais utiliser une méthode dans ma class Team du genre : incrementGameWon() ;
 
Donc voilà, en référencent mes Team dans un Match, je peux, grâce à la méthode "result" dans Match (Pour donner un résultat d'un match créer, j'utilise la méthode dans mon main du genre : m1.result(4, 9) ; pour donner le résultat), agir directement sur les statistiques (donc attributs) de Team qui sont protected. Parce que donner le résultat d'un match doit se traiter dans Match selon moi, mais ceci impliquera de mettre à jour les données des équipes une fois le résultat connu, c'est comme ça que j'ai pensé mais je me demande si c'est bien de faire ainsi. Aucune class n'hérite d'une autre mais comme une class est constituée d'objets d'une autre class j'arrive à travailler directement avec les attributs protected et je trouve ça moyennement propre. Je pensais que protected rendait accessible uniquement les attributs d'une class dans sa class et les class qui en hérite mais dans mon cas, je n'ai pas d' "extends", juste une class composée d'objet d'une autre class.
 
Pour l'instant l'idée était la suivante :
 
- J'enregistre toutes les Team,
 
- Je créer un objet GroupeStage qui me donnera un tableau 2D constitué de Match et qui représentera tout les matchs de pool.
 
- Une fois les résultats connus, on agira sur les objets Match un à un avec la méthode result. Cette méthode mettra chaque fois à jour les attributs de chaque Team.
 
- Une fois tout les matchs terminé, les objets Team auront leur statistiques. Il suffira de faire un tri (j'ai déjà fait une méthode dans Team compareTo qui utilise l'interface Comparable pour donner mon ordre de tri) et ainsi savoir quelles équipes pourront accédé au second tour.
 
J'espère que c'était plus ou moins clair! Merci encore!

Puisque on parle de règle de l'art ... une classe 'donnée' ou Bean ne contient que des getters et setters, et des affectations de variables dans le constructeur.
 
L'intelligence métier est déportée dans des classes utilitaires un peu fourre tout et donc de nom générique 'MatchUtils' 'MatchFactory'.
La je vois bien une classe MatchUtils avec la méthode result()...
 
Si les classes utilitaires implémentent un design pattern connu : une bonne pratique est de donner un nom suivant le design pattern : MatchStrategy MatchDecorator TeamAdapter ...

Ok merci! Je vais relire un peu la théorie sur les Patterns et voir comment réorganiser tout ceci!
 
Mais du coup, si je fais une class MatchStrategy, je devrais l'utiliser en tant qu'interface de class Match pour fait tout dans les règles de l'art, non?