Activité Gérons nos livres, responsabilité unique
Objectifs
À la fin de ce travail, vous devez :
- Connaître l’acronyme SOLID.
- Connaître l’énoncé du principe de responsabilité unique (Single responsibility principle).
Consigne
Le but de cette activité est de vous familiariser avec le principe de responsabilité unique, l’un des principes SOLID. Afin de respecter ce principe, vous allez être amené à scinder la classe Copy en une classe Copy simplifiée, une classe Loan (emprunt) et une classe LoanManager (gestionaire d’emprunts).
On vous demande de prendre connaissance de l’ensemble du document avant de réaliser les tâches décrites ci-après. Si vous ne parvenez pas à terminer le travail en classe, il vous appartient de prendre sur votre temps pour l’achever.
Le code des tests unitaires doit être utilisé tel quel et ne doit pas être modifié.
Le travail est individuel. Si vous rencontrez des difficultés que vous ne parvenez pas à surmonter seul, vous pouvez communiquer avec vos camarades en respectant le code d’honneur, ou demander de l’aide à votre enseignant. En dehors des heures de cours, il est également possible de poser des questions par courriel ou à l’aide de la messagerie instantanée de Teams.
Lorsque vous avez terminé l’activité, assurez-vous d’avoir atteint tous les objectifs.
Résultat attendu
Un projet Maven contenant les classes suivantes :
- Book, Author, Copy, LoanManager et Loan
- BookTest, AuthorTest, CopyTest, LoanManagerTest et LoanTest
Ressources
Logiciel :
- maven
- Visual Studio Code
Documents :
Situation
Vous participez au développement d’un logiciel de gestion de bibliothèque. On vous a assigné la tâche de modifier la classe Copy de manière à pouvoir conserver l’historique de tous les emprunts du livre correspondant.
Vous envisager une solution qui consiste à replacer les champs borrowedDate, returnedDate et borrowerName par des listes, mais vous trouver que cette solution est compliquée à réalisée et manque d’élégance. Vous vous tournez donc vers un collègue plus expérimenté pour avoir son avis sur la question.
Après avoir passé votre code en revue, il vous dit que la difficulté vient du fait que la classe Copy ne respecte pas le principe de responsabilité unique (single responsibility principle). Il vous explique que Robert C. Martin, l’homme à l’origine de ce principe, définit une responsabilité comme étant une raison de changer et qu’une classe ne devrait avoir qu’une seule raison de changer. Or, la classe Copy contient à la fois des attributs et des méthodes liés à la gestion des items de la bibliothèque (les exemplaires des livres) et à la gestion des emprunts. On pourrait donc avoir à modifier cette classe à cause d’un changement dans la gestion des documents ou à cause d’un changement dans la gestion des emprunts; cela fait au moins deux raisons. Votre collègue vous propose alors de diviser la classe Copy en une Copy, plus simple,qui ne contient qu’une référence à un livre, un identifiant et une localisation, une classe Loan qui représente un emprunt, et une classe LoanManager qui représente le gestionnaire d’emprunts (voir figure 1).
Avant de vous laisser à votre tâche, il vous indique encore que le principe de responsabilité unique est l’un des cinq principes SOLID. Ces principes peuvent être considérés comme des principes fondamentaux de la programmation orientée objet.
Mise en route
Lancez la machine virtuelle de développement avec Vagrant. Lancez Visual Studio Code, connectez-vous à la machine virtuelle et ouvrez la fenêtre de terminal intégré.
Rendez-vous dans le répertoire de projets (~/projects) et lancez la commande suivante :
1
git clone https://gitlab.epai-ict.ch/m226/gerons-nos-livres-responsabilite-unique.git --single-branch
Lorsque le système vous y invite, saisissez votre nom et votre mot de passe I-FR.
Déplacez-vous dans le répertoire gerons-nos-livres-responsabilite-unique et lancer la commande code -r . pour ouvrir le projet.
À vous de jouer !
Tâche
On vous demande de modifier la classe Copy qui représente les exemplaires physiques des livres de la bibliothèque, de réaliser la classe Loan qui représente les emprunts et, pour finir, de réaliser la classe LoanManager qui va nous permettre de gérer les emprunts conformément au diagramme de classes de la figure 1 et aux tests unitaires.
Chaque classe et chaque méthode publique doit être documentée à l’aide de commentaires javadoc.
Rappels :
- Commencez par créer le squelette des classes pour éliminer les erreurs de syntaxe dans les tests.
Demandez de l’aide en cas de besoin, mais essayez d’abord par vous-même et respectez toujours le code d’honneur !