TP 1

Dans ce premier devoir, on vous demande d’implémenter une modélisation rudimentaire de Skyjo.

Le modèle fait référence à : « tout ce qui est nécessaire pour représenter l’état ».
Pensez au modèle comme à l’ensemble des informations capturées si quelqu’un prenait une photo d’une partie de Skyjo en cours à n’importe quel moment.

Le code est une condition préalable à la note

Votre note est basée sur votre capacité à expliquer et à raisonner avec le code que vous soumettez, lors de l’examen oral subséquent. Un code fonctionnel est une condition préalable pour passer l’examen oral : bien que des fonctionnalités manquantes dans votre code entraînent une réduction de note, aucun point n’est accordé uniquement pour l’implémentation soumise.

Implémentation

On vous demande d’implémenter l’interface SkyjoModel, qui hérite implicitement de toutes les méthodes définies dans l’interface SkyjoModelReadOnly.
Cela signifie que votre implémentation du Model doit fournir au moins toutes les méthodes combinées des deux interfaces.

Illustration :

classDiagram
    class SkyjoModelReadOnly {
        <<interface>>
    }

    class SkyjoModel {
        <<interface>>
    }

    class YourImplementation {
    }

    SkyjoModelReadOnly <|-- SkyjoModel
    SkyjoModel <|.. YourImplementation

Les deux interfaces sont fournies :

Téléchargez les interfaces :
- SkyjoModelReadOnly.java
- SkyjoModel
Ne faites AUCUN changement aux interfaces ! Implémentez simplement les méthodes requises dans VOTRE classe.

Vous verrez également que certaines méthodes font référence à deux interfaces supplémentaires. Le code est bien sûr fourni :

Remarque : pour Card, vous devrez implémenter une méthode toString, retournant toujours une valeur de deux caractères, afin que le modèle puisse être correctement visualisé.

Si vous avez besoin des autres classes ou interfaces, visitez le repertoire des interfaces: https://gitlab.info.uqam.ca/mgl7010/interfaces/

Les interfaces sont de la documentation.

Pour les interfaces Java, il est courant de générer un site Web lisible par l’humain contenant tous les détails. C’est également le cas pour toutes les interfaces nécessaires à ce TP. Vous pouvez les consulter facilement ici : https://mgl7010.pages.info.uqam.ca/interfaces/

Méthodes

Les méthodes de l’interface du modèle sont uniquement des getters et setters de base.
Vous devez fournir une implémentation conforme à l’OO, c’est-à-dire :
- Veillez à ce qu’il ne soit pas possible de manipuler l’état sans passer par les getters et setters.
- Assurez-vous que l’état ne puisse pas être modifié lorsque votre implémentation est accédée via les méthodes de l’interface ReadOnly :
  - Protégez les secrets de la classe, ne renvoyez jamais une référence d’objet originale via un getter.
  - Pour les valeurs de retour objets, renvoyez une copie ou assurez-vous que les objets soient immuables.

Commencez avec les getters

L'interface graphique fait uniquement utilisation des getters, c'est-à-dire des méthodes de l'interface SkyjoModelReadOnly.java. Commencez avec ces méthodes lorsque vous implémentez votre solution, car elles suffisent pour afficher votre modèle.

Détails d’implémentation

Votre modèle Skyjo aura besoin d’une structure de données pour gérer les paquets de cartes.
- Implémentez cette structure de données à partir de zéro, c’est-à-dire n’utilisez pas de listes, tableaux, etc. pour réaliser les paquets. Implémentez plutôt votre propre classe dédiée.
- N’utilisez pas une collection Java existante ou un tableau pour cette tâche.

Modularisez votre modèle

Si vous placez toute votre implémentation du modèle dans une seule classe, elle sera gigantesque et cauchemardesque à développer. Avant de commencer à coder, réfléchissez aux composants du modèle qui pourraient être conceptualisés dans des classes dédiées. Un bon candidat pourrait être une classe Player, représentant les cartes détenues par un joueur spécifique.

Visualisation

Pour votre commodité, un Launcher et un Model Visualizer sont également fournis.

L’UI fournie peut être utilisée pour tester votre propre implémentation avant la remise.
En utilisant le code du lanceur fourni, votre modèle devrait afficher correctement les informations de début de partie :
- Paquet, pile de défausse (vous pouvez ignorer Buffer).
- Noms des joueurs, leurs scores.
- Cartes des joueurs, avec au moins deux cartes révélées par joueur.
L’état initial ne doit pas être codé en dur, c’est-à-dire qu’à chaque exécution du programme, une configuration initiale différente doit être affichée.

Remarque : Les informations affichées doivent être cohérentes, c’est-à-dire que la quantité de cartes et les informations affichées doivent être conformes aux règles et au matériel du jeu.

Illustration

Round:            1
Deck (81):     [??]
Discard ( 0):  [--]
Cache:         [--]

Max  (-1)        Ryan  (8)        Maram  (17)      QUENTIN  (18)
    [??] [??] [-1]   [??] [??] [??]   [11] [??] [ 6]   [??] [??] [ 8]
    [??] [ 0] [??]   [ 5] [??] [ 3]   [??] [??] [??]   [10] [??] [??]

    0: Take deck card.

Compatibilité

Pour assurer la compatibilité :

Ne faites pas de modifications au lanceur et au visualiseur fournis.
Incluez tout le code source fourni dans votre soumission.

Déclaration de contribution

Incluez un fichier PDF contenant les informations et la déclaration suivantes :

Informations

Par membre de l’équipe :

le pourcentage du travail auquel il a contribué.
2 méthodes pour lesquelles il se déclare expert désigné.

Déclaration

Incluez cette déclaration dans votre soumission, signez-la sur papier, prenez-en une photo et ajoutez-la à votre soumission.

Nous déclarons par la présente que nous n’avons pas utilisé d’IA générative pour produire du code pour ce TP, et que nous n’avons pas copié du code d’autres sources sans en donner le crédit dans les commentaires du programme.
Nous comprenons que l’inclusion de code généré par une IA ou la copie de code étranger sans crédit approprié constitue une infraction académique grave et sera signalée à la commission de plagiat de l’université, ce qui peut entraîner notre expulsion du programme d’études.

Signature : ____
Signature : ____
Signature : ____

Soumission

La remise se fait avant ... par courriel à schiedermeier.maximilian@uqam.ca.

Objet : TP1
Contenu :
- Un seul fichier zip avec les sources Java (Ne soumettez pas vos fichiers .class !)
- Déclaration de contribution, signée.

Réductions de points

Bien que votre note soit basée sur votre capacité à expliquer votre code, vous pouvez perdre des points (c.-à-d. que la note maximale que vous pouvez obtenir est réduite) si certaines demandes sont ignorées par votre solution :

Réductions liées à l’implémentation

Pas de déclaration de contribution : -100 %, à éviter absolument.
Interfaces fournies modifiées ou non utilisées, c.-à-d. pas d’implements SkyjoModel : -100 %, à éviter absolument.
Le code ne compile pas avec javac LauncherTP1.java, version 24 : -100 %, à éviter absolument.
Le code plante à l’exécution avec java LauncherTP1, version 24 : -100 %, à éviter absolument.
Dépendances non-JDK ajoutées / bibliothèques tierces utilisées : -100 %, à éviter absolument.
Paquet (deck) non implémenté avec une structure de données propre : -30 %
État codé en dur / ne change pas au redémarrage : -20 %
Méthodes du modèle manquantes/incomplètes : -10 % par méthode manquante/incomplète.
Méthodes trop compliquées : -5 % par méthode contenant plus de 25 lignes (les commentaires ne sont pas comptés)

Réductions liées à la soumission

Remise tardive : -30 % au départ de la date limite, puis -20 % supplémentaires pour chaque tranche de 24 h supplémentaire.
La soumission contient des fichiers inutiles/cachés ou des fichiers binaires (.class) : -5 % par fichier inutile.

DIVERS

Questions

Pour les questions liées aux exigences du TP, utilisez le forum Mattermost.
Ne partagez pas de code ou des parties de votre solution sur Mattermost.

Suggestions

Bien que ce ne soit pas une exigence stricte, et que cela n’accorde pas directement de points bonus, il est toujours bon de monter l’humeur du professeur avec quelques astuces :

Vérifiez doublement votre soumission avant de l’envoyer au prof :
- Envoyez-la d’abord à un membre de l’équipe. Laissez-le extraire le ZIP, compiler le code, etc. sur une autre machine.
- Si tout fonctionne, transférez le courriel au prof.
Formatez votre code : utilisez le raccourci de formatage d’IntelliJ, ainsi votre code sera plus facile à lire.
Revisitez les laboratoires : des parties des solutions pour ce TP ont été subtilement couvertes dans les labos. Si vous pensez qu’une solution de labo peut être réutilisée, indiquez-le dans un commentaire dans votre code.
Commentez votre code : utilisez le javadoc /** ... */ pour les méthodes, et des commentaires réguliers // en ligne.

Prennez l'habitude de coder et écrire des commentaires en anglais

Vous avez le droit de commenter en français, et la langue utilisée dans vos commentaires n’aura absolument aucun impact sur votre note. Cependant, gardez à l’esprit que l’informatique est une discipline internationale et, à long terme, vous devrez très probablement commenter en anglais. Mieux vaut s’y habituer tôt. Il en va de même pour les noms de variables et de méthodes : habituez-vous aux noms en anglais, cela facilite les choses sur le long terme. J’ai travaillé une fois dans une équipe internationale où chaque stagiaire ajoutait des commentaires et des noms dans sa langue maternelle, donc nous avions de l’anglais, de l’allemand, du français, de l’espagnol, même du chinois. Sans surprise, cela a eu un effet préjudiciable sur le projet.