TP noté de POO - Design Patterns

• Pas de détail inutile !
  - pas de champ private ou protected
  - en général pas de champ du tout
  - pas de méthodes privées, très peu de protected
• Ne pas oublier ce qui compte !
  - les liens entre classes. héritage, implémentation, dépendance, association
  - la navigabilité des liens
  - la cardinalité des liens
• Propre mais pas trop !
  - Il faut que vos schémas soient lisibles, compréhensibles
  - Mais utilisez la feuille blanche et le crayon. C'est largement suffisant.

Exercice 1 - Modelisation d'un système de fichier en mémoire

Votre entreprise souhaitre créer un module permettant de manipuler des fichiers en mémoire, donc sans disque.
Le cahier des charges suivant (simplifié) vous a été donné :

• Un système de fichiers est composé de fichiers et de répertoires. Un fichier contient du texte découpé en lignes. Un répertoire contient des fichiers.
• On souhaite avoir le minimum d'opérations sur le système de fichiers et permettre à n'importe qui utilisant le module de système de fichier d'écrire ses propres opérations.

Dans le but de faciliter la correction, on vous demande de dupliquer le code en le mettant dans un package Java différent pour chaque question, v1 pour la question 1, v2 pour la question 2, etc.
Comme base, on vous donne le code qu'un stagiaire a écrit :

et qui permet de modéliser un fichier.

1. Ajouter les commentaires de documentation en Anglais au format javadoc indiquant la responsabilité de la classe et ce que fait chaque méthode.
   Puis ajouter une classe Folder permettant de gérer les répertoires, sachant que
   • Un Folder possède un nom.
   • Il doit être possible d'ajouter un fichier à un répertoire mais impossible d'ajouter le même fichier à deux répertoires.
   • Il est impossible de créer un fichier sans répertoire.
   • il doit exister dans Folder une méthode list() qui renvoie un Stream de tous les fichiers de ce répertoire.
   Le code que vous devez produire doit être dans le package "v1".
2. En fait, on veut que les répertoires puissent aussi contenir des répertoires, et que la méthode list renvoie un stream de fichiers et de répertoires.
   Vous devrez écrire de plus un main de test d'une dizaine de lignes montrant comment votre design fonctionne.
   Faites dans un premier temps un diagramme UML de la solution proposée puis implanter celle-ci dans le package "v2". Indiquer, de plus, dans le commentaire de documentation de la classe Folder a quel design-pattern il correspond.
3. De même qu'un fichier ne peut être créé sans répertoire, il ne doit pas être possible de créer un répertoire qui ne soit pas "attaché" à un répertoire.
   Pour résoudre le problème du répertoire racine, on se propose d'écrire une classe FileSystem qui créera le premier répertoire racine avec comme nom "/", le seul qui ne sera pas rattaché à un autre répertoire.
   Il devra de plus être possible de créer plusieurs objets FileSystem.
   Faites le diagramme UML correspondant à votre solution.
   Modifier votre implantation en conséquence dans le package "v3", et écrivez une grosse dizaine de tests unitaires JUnit vérifiant que votre implantation est correcte.
4. On souhaite ajouter la possibilité de créer des liens symboliques sur les fichiers. Un lien symbolique possède un nom propre, est stocké dans un répertoire et possède, comme pour un fichier, les méthodes lines et append. Toute modification faite par la méthode append du fichier ou par celle du lien symbolique devra être visible à travers la méthode lines du fichier ou celle du lien symbolique.
   Modéliser dans un premier temps, votre solution sous forme d'un diagramme UML puis implanter votre solution dans le package "v4" en ajoutant les tests unitaires correspondant.
5. On souhaite ajouter la possibilité d'être prévenu à chaque fois d'un fichier a été mis à jour (au travers de la méthode append). Plusieurs codes qui le souhaitent pourront recevoir une notification indiquant que le fichier a été modifié.
   Quelle design pattern allons nous utiliser ? Fournissez un diagramme de classes UML correspondant.
   Modifier votre code dans le package "v5" et ajouter les tests unitaires correspondant.
6. On souhaite aussi pouvoir avoir des liens symboliques sur les répertoires. Une lien symbolique sur un répertoire devra possèder un nom spécifique et permettre d'effectuer toutes les opérations que l'on fait sur un répertoire. Comme pour le lien symbolique sur un fichier, tout changement à travers le lien symbolique devra être reflété aussi bien en utilisant le lien symbolique qu'en utilisant le répertoire sur lequel le lien symbolique a été créé.
   Modéliser dans un premier temps, votre solution sous forme d'un diagramme UML puis implanter votre solution dans le package "v6" en ajoutant les tests unitaires correspondant.
7. Enfin, on souhaite permettre d'effectuer des opérations sur une hierarchie de répertoire/fichier sans pour autant demander à un utilisateur de modifier le code de File et Folder.
   On vous demande pour cela d'implanter le design-pattern Visitor en suivant l'interface (à compléter) ci-dessous:

         public interface Visitor ... {
           public ...  visitFile(... file);
           public ...  visitFolder(... folder);
           public ...  visitSymbolicLinkFile(... symbolicLinkFile);
           public ...  visitSymbolicLinkFolder(... symbolicLinkFolder);
         }
        

   Reviser votre code en produisant une nouvelle version dans le package "v7" et modifier votre main pour inclure un exemple qui calcule le nombre total de lignes des fichiers stockés dans une sous-arborescence avec un visiteur en faisant attention de ne pas suivre les liens symboliques.