Différences

Ci-dessous, les différences entre deux révisions de la page.

--- departement_info:personnels:pb:pa3 [2025/04/21 19:20] – [Entrées-sorties] Brutus Philippe
+++ departement_info:personnels:pb:pa3 [2025/04/27 21:41] (Version actuelle) – [Exercice pour la prochaine séance] Brutus Philippe
@@ Ligne 301: / Ligne 301: @@
 ==== Singleton ====
-Une classe ayant au plus une instance est appelée un singleton. Pour empêcher le programmeur utilisant une telle classe de l'instancier plus d'une fois, on interdit l'utilisation du constructeur... en le rendant privé. Pour qu'il soit néanmoins possible d'instancier la classe, on propose une méthode de classe qui appelle le constructeur s'il n'y a pas encore d'instance de la classe ou renvoie l'instance déjà créée dans le cas contraire. Il faut pour cela mémoriser l'instance unique de la classe dans une variable de classe.
+Une classe ayant au plus une instance est appelée un singleton. Pour empêcher le programmeur utilisant une telle classe de l'instancier plus d'une fois, on interdit l'utilisation du constructeur... en le rendant privé ! Pour qu'il soit néanmoins possible d'instancier la classe, on propose une méthode de classe qui appelle le constructeur s'il n'y a pas encore d'instance de la classe ou renvoie l'instance déjà créée dans le cas contraire. Il faut pour cela mémoriser l'instance unique de la classe dans une variable de classe.
 {{:departement_info:personnels:pb:pa3:singleton.png?150x0&nolink}}
@@ Ligne 340: / Ligne 340: @@
 === Mandataire ===
-Un mandataire ou //Proxy// s'intercale entre une classe cliente C et une classe fournisseur F (objet du mandat). Au lieu d'utiliser un fournisseur de la classe F, la classe cliente donne procuration pour le faire à un objet de la classe M qui a la même API. Le mandataire relaie (ou pas) tous les appels de méthode à l'objet du mandat de la classe F mais peut effectuer d'autres traitements : mémorisation des résultats pour ne pas les redemander au fournisseur (proxy cache), bloquer certains appels (contrôle d'accès), journalisation...
+Un mandataire (//proxy//) s'intercale entre une classe cliente C et une classe fournisseur F (objet du mandat). Au lieu d'utiliser un fournisseur de la classe F, la classe cliente donne procuration pour le faire à un objet de la classe M qui a la même API. Le mandataire relaie (ou pas) tous les appels de méthode à l'objet du mandat de la classe F mais peut effectuer d'autres traitements : mémoriser les résultats pour ne pas les redemander au fournisseur (proxy cache), bloquer certains appels (contrôle d'accès), enregistrer les sollicitations au fournisseur (journalisation)...
+{{:departement_info:personnels:pb:pa3:mandataire.png?350x0&nolink}}
 {{:departement_info:personnels:pb:pa3:mandataire.zip|exemple de mandataire de journalisation}}
@@ Ligne 346: / Ligne 348: @@
 ----
-On remarquera que les opérations (EnregistrementTexte, ChargementTexte) s'appliquent à plusieurs classes (Alarme et ListeDAlarmes) et sont donc définies comme des visiteurs. Cela permet de plus de définir d'autres manières d'enregistrer ou charger (en binaire, en XML...) sans rien ajouter aux classes Alarme et ListeDAlarmes (presque) comme dans {{:departement_info:personnels:pb:pa3:lst14.zip|cette version}}.
+On remarquera que les opérations d'enregistrement et de chargement (EnregistrementTexte, ChargementTexte) s'appliquent à plusieurs classes (Heure - qui est en fait une interface, Alarme et ListeDAlarmes) et sont donc définies comme des visiteurs. Comme il y a différentes manières d'enregistrer ou charger (en mode texte, en binaire, en XML...), on définit plusieurs visiteurs pour implanter ces stratégies sans rien ajouter aux classes Heure, Alarme et ListeDAlarmes (presque) comme dans {{:departement_info:personnels:pb:pa3:lst14.zip|cette version}}.
 === Architecture en couches ===
@@ Ligne 365: / Ligne 367: @@
 comme dans {{:departement_info:personnels:pb:pa3:options_cumulables.zip|cet exemple}}.
-==== Pour partager le travail en cours ====
+----
+Dans la dernière version du projet Alarmes, l'enregistrement et le chargement sont définis comme des opérations en dehors des classes concernées (HeureV1, HeureV2, Alarme et ListeDAlarmes). Cela permet de les définir (et de définir d'autres opérations) sans ajouter ou modifier le code de ces classes. C'est bien le cas pour les classes HeureV1, HeureV2 et l'interface Heure ainsi que pour la classe Alarme. Mais ce n'est pas tout à fait le cas pour la classe ListeDalarmes qui dépend des classes définissant les opérations d'enregistrement et de chargement dans ses méthodes enregistreSous et charge.
+Pour découpler complètement la classe ListeDAlarmes des classes ChargementTexte, ChargementBinaire, EnregistrementTexte, EnregistrementXML et EnregistrementBinaire, il faudrait que l'instanciation des objets de ces classes soit réalisée en dehors de la classe ListeDAlarmes, par des méthodes de création d'objet qui créent et renvoient un objet dont la classe dépend de paramètre·s d'appel. Une classe qui crée des objets dont la classe dépend de paramètre·s est appelée une fabrique.
+==== Fabrique ====
+La fabrique est une classe de création d'objets. Elle permet d'instancier des objets dont le type est dérivé d'un type abstrait. La classe exacte de l'objet créé n'est pas connue par l'appelant.
+Dans {{:departement_info:personnels:pb:pa3:lst15.zip|cette version}} du projet Alarmes, la méthode enregistreSous n'instancie plus l'opération d'enregistrement et la méthode charge n'instancie plus l'opération de chargement. Les 2 méthodes délèguent cette instanciation à une fabrique (GestionDeFichiers) qui propose deux méthodes pour cela : operationPourEnregistrement et operationPourChargement. Chacune d'elle détermine la classe de l'objet à créer en fonction de l'argument d'appel, le nom complet de fichier, qui indique la stratégie par l'extension du nom de fichier.
+==== Exercice pour la prochaine séance ====
+Compléter {{:departement_info:personnels:pb:pa3:lst16.zip|ce projet}} pour que...\\
+- le nom associé à chaque alarme soit lu au chargement et écrit à l'enregistrement des fichiers de version 2 ;\\
+- l'on puisse lire les fichiers de version 1.
-{{:departement_info:personnels:pb:pa3:partage.zip|partage}}
+Les tests automatisés définis dans la classe de test TestEnregistrementEtChargementDeListeDAlarmes doivent tous réussir !
+Ce travail est à rendre par courrier électronique sous l'intitulé "TP05 NFP121" à l'adresse "philippe.brutus (à) caensup.fr" pour le 05/05/2025 à 8h00 avec en pièce jointe l'archive contenant les seuls fichiers modifiés ou ajoutés (dans leurs paquets respectifs).