Examen Java

Ce document est un examen de programmation Java portant sur la conception orientée objet (POO) appliquée à la gestion d’équipes de football. Il teste les compétences en modélisation des classes, encapsulation, polymorphisme, gestion des collections, et implémentation de méthodes spécifiques selon des règles métier.

D'après le document Examen Java

Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Document source

Examen Java

Programming · ENIT · PDF · 1 pages · 2016

Afficher l'aperçu du document

Consulter le document original →

Ce document est un examen de programmation Java portant sur la conception orientée objet (POO) appliquée à la gestion d’équipes de football. Il teste les compétences en modélisation des classes, encapsulation, polymorphisme, gestion des collections, et implémentation de méthodes spécifiques selon des règles métier.

Exercice 1

Il s'agit de développer les entités décrites (Personne, Joueur, Entraîneur, Médecin, Kinésithérapeute) en respectant les principes de la POO et les contraintes données.

Analyse et modélisation des classes

On doit représenter plusieurs types de personnes dans une équipe de football, avec des caractéristiques et comportements spécifiques :

  • Personne : entité de base identifiée par un CIN et un nom, avec un rôle.
  • Joueur : sportif avec un nom, un booléen indiquant s'il a joué en équipe nationale, un booléen blessé ou non, et une qualité de jeu initialisée à 50. Il peut jouer un match (augmenter sa qualité de 5%), s'entraîner (augmenter sa qualité de 2% si non blessé), et est comparable aux autres joueurs selon son état (blessé ou non) et sa qualité de jeu.
  • Entraîneur : sportif avec un nom, un booléen d'expérience en équipe nationale, capable d'entraîner une collection de joueurs, et de sélectionner les onze meilleurs joueurs selon le critère de comparaison défini.
  • Médecin : personnel médical avec un nom et un diplôme, capable de masser un joueur (augmenter qualité de 1% s’il n’est pas blessé), soigner un joueur (enlever la blessure), et sélectionner tous les joueurs non blessés parmi une collection.
  • Kinésithérapeute : similaire au médecin mais ne peut que masser les joueurs.

Étapes de conception

  1. Classe Personne : attributs CIN, nom, rôle (string ou enum). Constructeur paramétré. Méthode toString() retournant CIN, nom, rôle.
  2. Classe Sportif (hérite de Personne) : ajoute l'attribut boolean aJoueEnEquipeNationale.
  3. Classe Joueur (hérite de Sportif) : ajoute boolean blessé, double qualitéDeJeu initialisée à 50. Implémente Comparable<Joueur> selon la règle : un joueur non blessé est supérieur à un blessé, et si même état, celui avec qualitéDeJeu plus élevée est supérieur. Méthodes :
    • void jouerUnMatch() : augmente qualitéDeJeu de 5% (qualitéDeJeu = qualitéDeJeu * 1.05)
    • void sentrainer() : si non blessé, augmente qualitéDeJeu de 2% (qualitéDeJeu = qualitéDeJeu * 1.02)
  4. Classe Entraîneur (hérite de Sportif) : méthodes :
    • void entrainer(Collection<Joueur>) : entraîne les joueurs (implémentation non précisée, on suppose un appel à sentrainer() sur chaque joueur)
    • Collection<Joueur> selectionner(Collection<Joueur>) : retourne les 11 meilleurs joueurs selon la comparaison définie
  5. Classe Médecin (hérite de Personne) : ajoute attribut diplôme (String). Méthodes :
    • void masser(Joueur) : si joueur non blessé, augmente qualitéDeJeu de 1%
    • void soigner(Joueur) : enlève la blessure (blessé = false)
    • Collection<Joueur> selectionner(Collection<Joueur>) : retourne tous les joueurs non blessés
  6. Classe Kinésithérapeute (hérite de Personne) : mêmes attributs que Médecin sauf pas de diplôme précisé. Méthode :
    • void masser(Joueur) : même effet que Médecin

Remarques sur l’implémentation

  • Les constructeurs sont tous paramétrés, aucun constructeur par défaut.
  • Les accesseurs (getters) et mutateurs (setters) sont supposés fournis.
  • La méthode toString() de chaque classe doit inclure CIN, nom, et rôle (ex : "Joueur", "Entraîneur", etc.).
  • Le critère de comparaison des joueurs est : non blessé > blessé, puis qualité de jeu décroissante.

Exercice 2

Développer la classe Equipe et sa méthode toString() qui retourne le nom de l'équipe ainsi que les représentations textuelles de ses personnes.

Modélisation de la classe Equipe

Attributs :

  • String nom : nom de l'équipe
  • Collection<Personne> personnes : ensemble des personnes (joueurs, entraîneurs, médecins, kinésithérapeutes) appartenant à l'équipe

Méthode toString()

Cette méthode doit retourner une chaîne contenant :

  • Le nom de l'équipe
  • Pour chaque personne de l'équipe, sa représentation textuelle via sa propre méthode toString()

Par exemple :

Equipe : Les Bleus
Personnes :
CIN123 - Dupont - Joueur
CIN456 - Martin - Entraîneur
CIN789 - Durand - Médecin

La méthode toString() de Equipe concatène donc le nom et la liste des personnes.

Exercice 3

Comment représenter en un seul attribut une réunion de sélectionneurs.

Réponse

Les sélectionneurs sont des personnes capables de sélectionner des joueurs via la méthode :

CollectionDeJoueurs selectionner(CollectionDeJoueurs).

Dans la modélisation, les classes Entraîneur et Médecin sont des sélectionneurs. Pour représenter une réunion de sélectionneurs, on peut utiliser un attribut de type :

Collection<Sélectionneur> selectionneurs;

où Sélectionneur est une interface ou une superclasse abstraite définissant la méthode selectionner(Collection<Joueur>). Ainsi, on regroupe dans une seule collection tous les sélectionneurs, quels que soient leur type concret (entraîneur, médecin, etc.).

Exercice 4

Ajouter à la classe Equipe les méthodes nécessaires pour ajouter ou supprimer une personne, en se basant sur le CIN.

Analyse

On souhaite pouvoir :

  • Ajouter une personne à l'équipe si elle n'y est pas déjà (identifiée par son CIN)
  • Supprimer une personne de l'équipe selon son CIN

Code à rajouter

Supposons que l'attribut personnes est une collection (par exemple un Set<Personne> ou List<Personne>).

  1. Ajouter une personne :
    • Vérifier si une personne avec le même CIN existe déjà dans la collection.
    • Si non, ajouter la nouvelle personne.
  2. Supprimer une personne :
    • Parcourir la collection pour trouver la personne avec le CIN donné.
    • Si trouvée, la retirer de la collection.

Exemple de pseudo-code pour ajouter :

boolean ajouterPersonne(Personne p) {
  for (Personne pers : personnes) {
    if (pers.getCin().equals(p.getCin())) {
      return false; // déjà présente
    }
  }
  personnes.add(p);
  return true;
}

Exemple de pseudo-code pour supprimer :

boolean supprimerPersonne(String cin) {
  Iterator<Personne> it = personnes.iterator();
  while (it.hasNext()) {
    Personne pers = it.next();
    if (pers.getCin().equals(cin)) {
      it.remove();
      return true; // suppression réussie
    }
  }
  return false; // personne non trouvée
}

Ces méthodes permettent de gérer dynamiquement les membres de l'équipe en s'appuyant sur l'unicité du CIN.

Méthode

Ce sujet récompense une bonne maîtrise des principes de la programmation orientée objet : encapsulation, héritage, polymorphisme, et interfaces. Il faut modéliser clairement les classes et leurs relations, éviter la redondance, et utiliser les collections génériques de Java pour gérer des groupes d’objets.

Les erreurs pénalisées sont :

  • Ne pas respecter les signatures des méthodes données
  • Confondre les rôles et responsabilités des classes (ex : confondre joueur et entraîneur)
  • Ne pas implémenter la comparaison des joueurs selon le critère donné
  • Omettre la gestion des blessures dans les méthodes d’entraînement ou de massage
  • Ne pas fournir de constructeurs paramétrés ou de toString() conforme
  • Ne pas gérer correctement l’ajout/suppression par CIN dans la classe Equipe

En résumé, il faut structurer le code pour qu’il soit extensible et réutilisable, en tirant parti du polymorphisme et des interfaces, et respecter strictement les spécifications fonctionnelles.

Partager

Commentaires

Aucun commentaire pour le moment. Posez la première question.

Les commentaires sont relus avant publication. Votre e-mail n'est jamais affiché.

← Toutes les révisions