Activité Introduction aux patrons de conception : patrons de structure

EPAI , () — CC BY-NC-SA

Consigne

Pour ce travail on vous demande de prendre connaissance de la situation et de réaliser les tâches proposées. Si vous ne parvenez pas à terminer le travail en classe, il vous appartient de prendre sur votre temps pour l’achever.

Le travail est individuel. Vous pouvez communiquer en respectant le code d’honneur.

Situation

Vous êtes développeur dans un projet de logiciel de gestion de bibliothèque. Vous êtes actuellement confronté à un problème. En effet, en cherchant à respecter les principes SOLID et tout particulièrement le principe d’inversion de dépendance – qui stipule que le code ne devrait dépendre que d’abstraction – le nombre de classes de votre application a fortement augmenté et vous commencez à avoir du mal à vous y retrouver.

Vous en parlez à un collègue qui vous propose d’utiliser des packages pour regrouper les classes. Vous connaissez les packages, mais vous ne savez pas trop comment choisir la manière de regrouper les classes. Vous lui en faites part et il vous propose de le faire de l’une des manières décrites par Robert C. Martin (Uncle Bob) dans son ouvrage « Clean Architecture » (voir figure 1).

Fig. 1 – structure des packages
Fig. 1 – structure des packages

Le package domain contient les classes et les interfaces qui représentent les entités de l’application. Dans notre cas, il s’agit des livres (book), des documentaires (documentary), des clients (patron), les exemplaires (copy), etc. (figure 2). En regardant le contenu de ce package, il est possible de se faire rapidement une idée de ce que fait l’application. Martin parle de screaming architecture, une architecture qui parle d’elle-même, de la même manière que l’architecture d’un bâtiment vous permet de savoir d’un coup d’oeil s’il s’agit plutôt d’une ferme, d’une école ou d’un grand magasin.

Fig. 2 – domain package
Fig. 2 – domain package (diagramme de classe simplifiée)

Les packages ui et data représente des ports de l’application, c’est-à-dire ce qui permet à un utilisateur de manipuler les objets du domaine, d’exposer ces objets à l’aide d’une api web, de les enregistrer dans une base de données ou encore de les envoyer à une autre application. Dans notre cas, le package data rassemble les classes qui permettent d’accéder aux données qui se trouve dans les fichiers (figure 3).

Fig. 3 – data.books package
Fig. 3 – data/books package (diagramme de classe simplifiée)

Le package ui, quant à lui, peut contenir un package cli si l’on souhaite réaliser une interface en ligne de commande ou un package web si l’on préfère une interface utilisateur web (p. ex. avec Javalin).

Fig. 4 – ui/cli package
Fig. 4 – ui/cli package (diagramme de classe simplifiée)

Résultat attendu

  • Un projet Maven contenant les classes décrites

  • Un document contenant les réponses aux questions

Objectifs

À la fin de ce travail, vous devez :

  1. Connaître le principe d’inversion des dépendances.
  2. Connaître une manière de regrouper les classes en packages.
  3. Connaître le patron de conception “Facade”.
  4. Connaître le patron de conception “Singleton”.
  5. Connaître la notion de visibilité de package (friend).
  6. Être capable de produire un diagramme de classe et un diagramme d’interaction à partir du code.

Ressources

Logiciel :

  • maven
  • Visual Studio Code
  • Visual Paradigm

Documents :

  • Support de cours pages 61 à 63
  • SOLID

Mise en route

Rendez-vous dans le répertoire de vos projets, lancez la commande ci-après et lorsque le système vous le demande, saisissez votre nom et votre mot de passe I-FR.

1

git clone https://gitlab.epai-ict.ch/m226/acme-library.git --single-branch

Déplacez-vous dans le répertoire acme-library et lancer la commande code . pour ouvrir le projet dans VSC (Visual Studio Code).

À vous de jouer !

Tâches

  1. Analysez le code de la classe CopyDataMapperBuilder et étudiez la manière dont le builder utilise un BookDataMapper, un DocumentaryDataMapper et un PeriodicalDataMapper pour construire les objets de type Copy.

  2. Utilisez le même principe pour construire les objets de types Loan (vous devez réaliser la classe LoanDataMapperBuilder).

  3. Faite une recherche à propos du patron de conception “Facade” (facade design pattern).

  4. Analysez le code qui permet d’initialiser le singleton DataMapperFacade et utilisez le logiciel Visual Paradigm pour dessiner le diagramme de classe et le diagramme d’interaction correspondant. (Attention : ne cherchez pas à dessiner le diagramme d’interaction complet)

  5. Pourquoi doit-on utiliser une classe abstraite pour DataMapperFacade ? Pourquoi ne pourrait-on pas utiliser une interface ?

  6. Pourquoi ne pourrait-on pas utiliser le pattern “Singleton” original ? (Pourquoi la classe DataMapperFacade ne peut-elle pas instancier elle-même les différentes factories de data mapper ?)

  7. Ajouter un package web dans le package ui, implémentez la même vue que le programme en ligne de commande en utilisant Javalin puis modifiez aussi peu de code que possible dans la procédure main pour lancer l’application Web.

  8. Utilisez l’outil de refactoring “rename symbol” pour renommer la méthode de création de toutes les factories de data mapper en createFromFile. Attention : il ne s’agit pas de chercher et remplacer! Vous devez apprendre à utiliser l’outil de refactoring.

  9. En Java, est-il possible de ne pas spécifier de modificateur de visibilité (public, private, protected) pour une classe ou un membre ? Si oui, quelle est la visibilité de la classe ou du membre ? À quoi cela peut-il servir ?

Demandez de l’aide en cas de besoin, mais essayez d’abord par vous-même et respectez toujours le code d’honneur !