feat(design): rewrite DESIGN.md

DESIGN.md

@@ -1,64 +1,37 @@
 # Document de design
 
-Ceci est le document de template pour décrire l'architecture de votre programme. Vous pouvez le modifier à votre guise, mais assurez-vous de répondre à toutes les questions posées.
-***Suivant certaines architectures, certaines des questions peuvent ne pas être pertinentes. Dans ce cas, vous pouvez les ignorer.***
-Vous pouvez utiliser autant de diagrammes que vous le souhaitez pour expliquer votre architecture.
-Nous vous conseillons d'utiliser le logiciel PlantUML pour générer vos diagrammes.
+-------------------------------------
+Notre programme a été pensé pour être le plus évolutif possible, et avec des ajouts d'implémentations d'api simples. 
 
-## Schéma général
+Pour se faire le projet est décomposé en plusieurs composants :
+* L'affichage 
+* Les Apis météo
+* Système de requête
 
-Décrivez ici le schéma général de votre programme. Quels sont les composants principaux et comment interagissent-ils ?
+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
+* 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
 
-On a 2 principaux composants :
+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
 
-* WeatherDataAPI
-* WeatherDisplay
+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.
 
-WeatherDisplay contient un ensemble d'instances de WeatherDisplay. Chacune de ces instances retournent des données ayant l'interface WeatherData, ce qui permet au WeatherDisplay de les afficher.
+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
 
-## Utilisation du polymorphisme
+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.
 
-Comment utilisez-vous le polymorphisme dans votre programme ?
+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)
+Ces exceptions sont laissées à la charge de l'affichage qui décidera de la marche à suivre dans ces cas là.
 
-Nous utilisons les interfaces suivantes servant à définir les parties publiques de nos Classes :
-
-* WeatherDataAPI
-* WeatherDisplay
-
-## Utilisation de la délégation
-
-Comment utilisez-vous la délégation dans votre programme ?
-
-Nous avons essayé de mettre en oeuvre un maximum de forme de délégation dans le projet.
-
-Voici les principales formes de délégations qui se trouvent dans le projet :
-
-### JSONFetcher
-
-Les requêtes HTTP(S) et la transformation de la réponse en JSONObject est abstraite grâce à la classe JSONFetcher
-
-### City
-
-Nous utilisons une classe City afin de stocker le nom d'une ville, et de faire le lien avec ses coordonnées.
-
-Cela permet d'abstraire un appel à l'API api-adresse.data.gouv.fr pour obtenir les coordonnées depuis le nom de la ville.
-
-## Utilisation de l'héritage
-
-Comment utilisez-vous l'héritage dans votre programme ?
-
-Nous avons limité au maximum l'héritage dans le projet et nous sommes concentrés sur des relations de composition.
-
-Au final, pour permettre un système de cache, les trois classes WeatherAPI, OpenMeteo et OpenWeatherMap héritent d'une classe WeatherDataCachedAPI.
-
-## Utilisation de la généricité
-
-Comment utilisez-vous la généricité dans votre programme ?
-
-Nous n'avons pas eu besoin de généricité dans notre programme.
-
-## Utilisation des exceptions
-
-Comment utilisez-vous les exceptions dans votre programme ?
-
-Nous utilisons WeatherFetchingException qui est une Exception qui est envoyée lorsqu'
+-------------------------------------