ndacremont/weather-aggregator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: update design.md with the cache

Browse Source
This commit is contained in:
Nemo D'ACREMONT 2024-12-20 16:41:18 +01:00
parent b05e009497
commit edc3243a8e
1 changed files with 16 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
DESIGN.md
View File

@ -5,33 +5,34 @@ Notre programme a été pensé pour être le plus évolutif possible, et avec de
Pour se faire le projet est décomposé en plusieurs composants :
* L'affichage
* Les Apis météo
* Les APIs météo
* Système de requête
Cette décomposition se traduit par la création de plusieurs interfaces et composants (et est visible sur le diagramme de classe) :
* WeatherDisplay pour l'affichage de tel sorte à avoir plusieurs affichages possibles
* WeatherDataApi pour l'implémentation des Apis standardisées grâce à l'objet WeatherData
* WeatherDisplay pour l'affichage de telle sorte à avoir plusieurs affichages possibles
* WeatherDataApi pour l'implémentation des APIs standardisées grâce à l'objet WeatherData
* JSONFetcher qui s'occupe de faire les requêtes aux APIs et permet par ce mécanisme de mock les tests en simulant la réponse d'un serveur api
La mise en relation de ces différents composants sont possibles grâce au polymorphisme :
L'affichage utilise des instances de WeatherDataApi pour faire l'affichage mais on lui donne en réalité des implémentations des apis tel que OpenMeteo ou OpenWeatherMap
L'affichage utilise des instances de WeatherDataApi pour faire l'affichage, mais on lui donne en réalité des implémentations des APIs tel que OpenMeteo ou OpenWeatherMap.
En plus de cela, nous avons décidé d'abstraire d'autres parties du code pour déléguer certaines taches :
* On utilise un type City dans nos implémentations d'apis de sorte à abstraire la récupération des coordonnées GPS à partir d'un nom de ville (à l'aide de l'api du gouvernement).
* Le JSONFetcher abstrait la partie requête http(s) lors d'un appel à l'api. Il renvoit le résultat d'une requête sous forme d'un JSON.
* On utilise un type City dans nos implémentations d'APIs de sorte à abstraire la récupération des coordonnées GPS à partir d'un nom de ville (à l'aide de l'api du gouvernement).
* Le JSONFetcher abstrait la partie requête HTTP(S) lors d'un appel à l'api. Il renvoie le résultat d'une requête sous forme d'un JSON.
Nous avons décidé d'ajouter un système de cache à l'implémentation de nos apis. C'est une fonctionnalité supplémentaire et pour ne pas avoir à changer toutes les implémentations d'apis deux solutions s'offraient à nous :
Nous avons décidé d'ajouter un système de cache à l'implémentation de nos apis. C'est une fonctionnalité supplémentaire et pour ne pas avoir à changer toutes les implémentations d'APIs deux solutions s'offraient à nous :
* Faire le cache au niveau du JSONFetcher :
* Complétement transparent pour les implémentations (si une requête a déjà été faite on renvoit la requête cachée)
* Mais couteuse en terme d'espace et ne permet pas de standardiser le stockage des données (ce que le sujet semble sous entendre)
* Faire une Api de cache dont les autres implémentations hériteraient
* Complétement transparent pour les implémentations (si une requête a déjà été faite, on renvoie la requête cachée)
* Mais couteuse en terme d'espace et ne permet pas de standardiser le stockage des données (ce que le sujet semble sous-entendre)
* Créer une classe abstraite ayant un système de cache intégré et ayant une méthode abstraite pour récupérer des données de type WeatherData
Nous sommes partis sur la deuxième option, car elle demandait peu de modification sur le code existant. De plus, si on voit le paquet comme une bibliothèque, ce découpage permet simplement de laisser la liberté à l'utilisateur d'utiliser ou non un système de cache déjà codé.
Nous sommes partis sur la deuxième option.
Chaque implémentation souhaitant un système de cache hérite de la class abstraite WeatherDataCache et implémente simplement les fonctions de récupération de la météo comme si il n'y avait pas de cache.
C'est une solution simple et complète qui permet de gérer le cache efficacement.
Pour finir les exceptions qui peuvent être envoyées lors de requêtes aux apis sont englobés dans une exception WeatherFetchingException.
Il existe plusieurs variantes (qui hérite de cette exception mère) qui permettent d'avoir plus de détails sur le type d'exception (si il s'agit d'un problème réseau, de la ville introuvable etc)
Pour finir les exceptions qui peuvent être envoyées lors de requêtes aux APIs sont englobés dans une exception WeatherFetchingException.
Il existe plusieurs variantes (qui hérite de cette exception mère) qui permettent d'avoir plus de détails sur le type d'exception (s'il s'agit d'un problème réseau, de la ville introuvable etc)
Ces exceptions sont laissées à la charge de l'affichage qui décidera de la marche à suivre dans ces cas là.
-------------------------------------