TD 3 • Service de réservation
Cartouche
| Champ | Valeur |
|---|---|
| Auteur·e | Élise |
| Édition | 2024-04-25 |
| Durée | 2 séances |
| Taille des équipes | 2~4 personnes login des auteur·rice·s dans author.txt |
| Rendu | via git, dépôt $YEAR_node_api, droits en lecture à delivery_collector |
Barème
| Critère | PA |
|---|---|
| E 1 termes | 3 |
| E 2 types créneau et plage, classe service CRUD | 3 |
| E 3 classes d’erreur, throw | 4 |
| E 4 TU | 4 |
| E 5 génération des créneaux | 3 |
| E 6 inscriptions | 3 |
| Malus : Coding Style (par fichier sale) | -5 |
| Malus : Dépôt Sale (par dépôt) | -5 |
Introduction
Petite présentation du projet. Notre objectif c’est de programmer une API de créneaux de reservation.
Ce que l’on veut pouvoir faire avec notre API c’est :
- créer/gérer des événements, qui contiennent des créneaux ;
- faciliter la génération de créneaux selon plusieurs variables :
- nombre de créneau
- durée des créneau
- est-ce qu’il y a des pauses ? tous les combien ? de combien de temps ?
- permettre à des utilisateurs de s’inscrire sur un créneau ;
- vérifier que le tout est cohérent (un utilisateur n’est pas inscrit à deux endroits en même temps).
Les événements auront les propriétés suivantes :
- un nom ;
- un descriptif ;
- une date de début ;
- une date de fin.
Les créneaux :
- une date de début ;
- de fin ;
- une personne inscrite.
Des cas concrets d’utilisation d’une telle API :
- entreprises et freelances qui proposent à leur client de prendre RDV :
- à la https://cal.com/fr,
- à la https://calendly.com/fr,
- créneaux de suivis/soutenance en école :
- au lieu de faire des listes alphabétique, du hazard ou une criée, permettre à des étudiants de choisir le créneaux qui convient le plus,
- permet aussi la prise de RDV en dehors de sessions de cours ;
- rendez-vous médicaux avec des professionnels de santé :
- à la doctolib.
Étape 1 : dites les termes
Notre terminologie en français n’étant pas très adaptée au code source, commençons par trouver des traductions qui seraient appropriées.
Choisissez des noms en anglais pour les différents aspects de notre domaine, de notre logique métier :
- événements/plages/séries de créneaux
- dates début et fin
- nom
- descriptif
- créneaux
- dates début et fin
- personne inscrite
- paramètres de génération de créneau
- nombre
- durée
- intervalle de pause
- durée de pause
Étape 2 : écrire les types/interfaces
Dans un fichier source et module reservation.service.ts.
Créez un type (ou une interface, peu importe) pour les créneaux. Vous devez au moins avoir des champs pour un ID une date de début, de fin, un titre, une description, une personne inscrite.
Créez un type pour les plages de créneaux. Il doit contenir un ID, un nom, une date de début et de fin.
Créez une classe ReservationService qui va nous servir pour garder en mémoire nos créneaux de reservation et nos plages de créneaux. Et toutes les fonctions membres de cette classe nous permettrons de faire des opérations communes comme de la création, modification, suppression.
Sur cette classe vous devez implémenter des fonctions pour :
- insérer une nouvelle plage (et génération de l’ID) ;
- insérer un nouveau créneau (forcément associé à/dans une plage) (et génération de l’ID) ;
- obtenir une plage existante par ID ;
- obtenir un créneau existant par ID ;
- obtenir tous les créneaux d’une plage par ID de plage ;
- supprimer une plage par ID (et de tous ces créneaux) ;
- supprimer un créneau par ID ;
- modifier une plage par ID ;
- modifier un créneau par ID.
Étape 3 : Gestion d’erreur
Toujours dans un fichier source et module reservation.service.ts.
Que ce passe-t’il si on vous demande un créneau qui n’existe pas ? Actuellement il y a grande chance que vos fonctions renvoient undefined ou null si vous n’avez pas trouvé ce que vous cherchiez, voir qu’elles ne fassent rien du tout dans le cas de fonctions de modification ou suppression. On ne peut pas se contenter de cela.
En TS on peut utiliser des throw/try/catch pour indiquer une erreur et adopter un comportement quand elle se produit.
Écrivez une classe ReservationServiceErr qui implémente Error. L’objectif dans une classe d’erreur est d’encoder des informations qui peuvent aider l’appellant à savoir quoi faire ensuite.
Faites prendre à la construction de votre classe :
- un sujet qui peut avoir pour valeur le nom d’une de vos classes sur lesquelles le service travaille ;
- une raison, soit pourquoi la fonction a
throwune erreur.
Maintenant, ajoutez à vos fonctions des throw lorsqu’elles ne trouvent pas un créneau ou une plage.
L’objectif de cette classe d’erreur c’est que lorsqu’elle est catch quelque part, elle peut permettre à notre programme de récupérer si ça n’est pas une erreur importante. Mettons vous avec une action à faire seulement si vous trouvez un élément avec un Id spécifique : si la fonction vous throw un ReservationServiceErr avec une raison "NotFound", votre fonction peut continuer son travail sans effectuer ladite action.
Étape 4 : tests unitaires
Écrivez les tests unitaires de votre service. Il faut que vous testiez les cas normaux et les cas d’erreurs.
Étape 5 : génération de créneaux
Dans le TD précédent, nous avions généré des listes de créneaux avec plusieurs paramètres. C’était dans l’objectif de les ajouter à notre ReservationService.
Ajoutez à votre classe ReservationService une fonction de génération de créneaux. Faites valider le nom que vous lui donnez.
La fonction doit prendre en paramètre :
- la plage de créneau sur laquelle créer ces créneaux ;
- une date de départ ;
- le nombre de créneaux totaux ;
- l’espacement en minutes entre deux créneaux ;
- le nombre de créneaux avant une pause (ou rien s’il n’y a pas de pause) ;
- la durée en minutes de la pause (ou rien s’il n’y a pas de pause).
Les créneaux générés doivent être stockés dans la classe. Les créneaux générés doivent aussi être renvoyés dans un tableau.
Enfin, écrivez les tests unitaires de cette fonction.
Étape 6 : inscriptions
Ajoutez au service une fonction membre pour inscrire une personne à un créneau. Ce qui identifie une personne c’est une chaîne de caractère contenant son login. Vous n’avez pas de vérification particulière à faire sur la véracité du login : partez du principe qu’il est correct.
Votre fonction doit cependant vérifier cette personne n’est inscrite à aucun autre créneau qui chevauche celui auquel on essaie de s’inscrire. En cas de chevauchement : faites un throw. Pareil dans le cas où le créneau n’existe pas.
Vous devez aussi vérifier que la personne n’est inscrite à aucun autre créneau de la même plage.