3.0 KiB
Document de design
Notre programme a été pensé pour être le plus évolutif possible, et avec des ajouts d'implémentations d'api simples.
Pour se faire le projet est décomposé en plusieurs composants :
- L'affichage
- 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 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.
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 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 :
- Faire le cache au niveau du JSONFetcher :
- 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é.
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 (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à.