Différences

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

--- departement_info:personnels:pb:pa3 [2025/03/17 18:07] – [Notion de stratégie] Brutus Philippe
+++ departement_info:personnels:pb:pa3 [2025/04/04 14:05] (Version actuelle) – [Pour partager le travail en cours] Brutus Philippe
@@ Ligne 96: / Ligne 96: @@
 Le projet {{:departement_info:personnels:pb:pa3:bonjour2.zip|bonjour}} met en œuvre une organisation en paquets des classes.\\
-{{:departement_info:personnels:pb:pa3:bonjour2.png?300x0&nolink}}
+{{:departement_info:personnels:pb:pa3:bonjour2.png?250x0&nolink}}
 ==== Abstraction ====
@@ Ligne 198: / Ligne 198: @@
 On parle de stratégies lorsqu'il est possible de réaliser une opération sur un même objet de différentes manières. On peut par exemple afficher tous les éléments d'une collection horizontalement - les uns à la suite des autres, ou verticalement - les uns en dessous des autres. On peut aussi trier une collection en utilisant différentes méthodes de tri ([[http://lwh.free.fr/pages/algo/tri/tri_bulle.html|tri bulle]], [[http://lwh.free.fr/pages/algo/tri/tri_selection.html|tri sélection]], [[http://lwh.free.fr/pages/algo/tri/tri_fusion.html|tri fusion]], [[http://lwh.free.fr/pages/algo/tri/tri_rapide.html|tri rapide]] ...), ou encore chercher dans une liste chaînée un élément désigné par son indice en commençant le parcours par le début de la liste (indice < moitié du nombre d'éléments) ou en commençant le parcours par la fin de la liste (indice >= moitié du nombre d'éléments).
-Pour cela, on définit les différentes méthodes de traitement sous la forme d'une méthode //execute()// dans différentes classes qui implantent chacune l'interface //[[https://fr.wikipedia.org/wiki/Strat%C3%A9gie_(patron_de_conception)|Strategy]]//, qui spécifie ces classes de traitement.
+Pour cela, on définit les différentes méthodes de traitement sous la forme d'une méthode //execute()// dans différentes classes qui implantent chacune l'interface [[https://fr.wikibooks.org/wiki/Patrons_de_conception/Strat%C3%A9gie|Strategie]], qui spécifie ces classes de traitement.
 {{:departement_info:personnels:pb:pa3:stratégie.png?200x0&nolink}}
@@ Ligne 241: / Ligne 241: @@
 Une {{:departement_info:personnels:pb:pa3:appliGraphique.pdf|application avec interface graphique}} doit, pour réagir aux sollicitations de l'utilisateur, définir des méthodes de traitement d'événements qui sont spécifiées dans des interfaces dédiées (//[[https://docs.oracle.com/javase/8/docs/api/java/awt/event/KeyListener.html|KeyListener]]// pour les événements clavier et //[[https://docs.oracle.com/javase/8/docs/api/java/awt/event/MouseListener.html|MouseListener]]// et //[[https://docs.oracle.com/javase/8/docs/api/java/awt/event/MouseMotionListener.html|MouseMotionListener]]// pour les événements souris). Elle doit aussi recenser le ou les objets qui vont exécuter ces méthodes (instances de classes qui implantent ces interfaces) auprès de la source d'événements (une fenêtre par exemple).
-Remarque : La définition de deux interfaces //MouseListener// et //MouseMotionListener// pour gérer les sollicitations à la souris (//MouseEvent//) est justifiée parce que beaucoup d'applications utilisent la souris (clic, double-clic, entrée ou sortie du pointeur dans ou d'une zone de l'écran...) sans utiliser d'autres sollicitations liées au mouvement de la souris (comme le glisser-déposer). C'est une application du principe I de SOLID (//[[https://fr.wikipedia.org/wiki/Principe_de_s%C3%A9gr%C3%A9gation_des_interfaces|ségregation d'interface]]//).
+Remarque : La définition de deux interfaces //MouseListener// et //MouseMotionListener// pour gérer les sollicitations à la souris (//MouseEvent//) est justifiée parce que beaucoup d'applications utilisent la souris (clic, double-clic, entrée ou sortie du pointeur dans ou d'une zone de l'écran...) sans utiliser d'autres sollicitations liées au mouvement de la souris (comme le glisser-déposer). C'est une application du principe ''I'' de SOLID (//[[https://fr.wikipedia.org/wiki/Principe_de_s%C3%A9gr%C3%A9gation_des_interfaces|interface segregation]]//).
 {{:departement_info:personnels:pb:pa3:appliDeDessin1.zip|Ce projet}} définit une application affichant une fenêtre dans laquelle l'utilisateur peut dessiner à la souris tout en changeant l'épaisseur (caractères 1 à 9) et la couleur (caractère R pour rouge, V pour vert, B pour bleu, J pour jaune, N pour noir) de dessin. Cela illustre la programmation événementielle et la possibilité pour l'utilisateur de solliciter l'application en même temps au clavier et à la souris (enchevêtrement des événements).
@@ Ligne 259: / Ligne 259: @@
 Le modèle ne peut pas dépendre de la vue (principe de séparation) et la vue doit traiter (ici afficher) correctement le modèle, c'est-à-dire sans tester le type des objets du modèle. Dans ces conditions, où peut-on définir les méthode d'affichage du modèle ? Dans la vue puisque le modèle doit être indépendant de la vue, mais pas dans la classe FenetreDeDessin, puisque cela oblige à tester le type des objets du modèle. Seule possibilité, dans un classe du paquet vue qui n'est pas la classe FenetreDeDessin. Une classe qui connaît la vue et le modèle... un ami commun.
-De manière très générale, il s'agit ici de réaliser une opération (l'affichage dans notre exemple) sur des objets de types différents (traces et étoiles dans notre exemple) en définissant les méthodes correspondantes en dehors des classes concernées (Dessin, Trace et Etoile dans notre exemple). C'est un peu comme quand on nous demande quelque chose qu'on ne sait pas, que celui qui demande ne peut le faire, ni nous non plus puisqu'on ne sait pas... On fait appel à un ami ([[https://fr.wikipedia.org/wiki/Qui_veut_gagner_des_millions_%3F|joker dans le jeu "Qui veut gagner des millions"]]). Ou encore quand on nous dit de nous soigner parce qu'on se plaint de douleurs alors que nous ne sommes pas médecin. On ne le fait pas nous-même (la méthode n'est pas définie dans la classe de l'objet qui doit réaliser une opération) mais on le fait faire par un tiers (de confiance), le médecin ou le chirurgien. Ce tiers peut réaliser l'opération sur des objets de classes différentes (un vétérinaire peut opérer un chat, un chien, un hamster...).
+De manière très générale, il s'agit ici de réaliser une opération (l'affichage dans notre exemple) sur des objets de types différents (traces et étoiles dans notre exemple) en définissant les méthodes correspondantes en dehors des classes concernées (Dessin, Trace et Etoile dans notre exemple). C'est un peu comme quand on nous demande quelque chose qu'on ne sait pas, que celui qui demande ne peut le faire, ni nous non plus puisqu'on ne sait pas... On fait appel à un ami ([[https://fr.wikipedia.org/wiki/Qui_veut_gagner_des_millions_%3F|joker dans le jeu "Qui veut gagner des millions"]]). Ou encore quand on nous dit de nous soigner parce qu'on se plaint de douleurs alors que nous ne sommes pas médecin. On ne le fait pas nous-même (la méthode n'est pas définie dans la classe de l'objet qui doit réaliser une opération) mais on le fait faire par un tiers (de confiance), le médecin ou le chirurgien. Ce tiers peut réaliser l'opération sur des objets de classes différentes (un vétérinaire peut opérer un chat, un chien, un serpent...).
-On définit une interface **Operable** qui spécifie une seule opération. Cette interface doit être implantée par toutes les classes pour lesquelles on souhaite que l'opération les concernant soit définie en dehors d'elle. On définit une interface **Operation** qui spécifie l'opération pour chacune des classes concernée. On définit une classe pour l'opération en question, qui implante l'interface Operation et définie une méthode pour chaque type d'objet concerné. C'est ce qui est fait dans {{:departement_info:personnels:pb:pa3:appliDeDessin6.zip|cette version}} dont on examinera les interfaces Operable et Operation du paquet modele et la classe Affichage du paquet vue qui définit la méthode d'affichage pour les 3 classes concernées (Dessin, Trace, Etoile). Dans les classes Trace et Etoile du paquet vue, on a défini une méthode réalise qui permet la réalisation de l'opération (Affichage ou autre) très simplement, puisque le traitement est délégué à l'opération (ami ou médecin ou chirurgien) qui va agir sur l'objet.
+On définit une interface **Operable** qui spécifie une seule opération ''realise(Operation)''. Cette interface doit être implantée par toutes les classes pour lesquelles on souhaite que l'opération les concernant soit définie en dehors d'elle. On définit une interface **Operation** qui spécifie l'opération pour chacune des classes concernée. On définit une classe pour l'opération en question, qui implante l'interface Operation et définit une méthode pour chaque type d'objet concerné. C'est ce qui est fait dans {{:departement_info:personnels:pb:pa3:appliDeDessin6.zip|cette version}} dont on examinera les interfaces Operable et Operation du paquet modele et la classe Affichage du paquet vue qui définit la méthode d'affichage pour les 3 classes concernées (Dessin, Trace, Etoile). Dans les classes Trace et Etoile du paquet vue, on a défini une méthode ''realise(Operation'' qui permet la réalisation de l'opération (Affichage ou autre) très simplement, puisque le traitement est délégué à l'opération (ami ou médecin ou chirurgien) qui va agir sur l'objet (''op.opereSur(this)'').
 === Et les différentes couleurs et épaisseurs ? ===
@@ Ligne 276: / Ligne 276: @@
  ...
-Depuis 1998 avec la sortie de java 2, la bibliothèque Swing offre la possibilité de créer des interfaces indépendantes du système d’exploitation et propose plusieurs choix d'apparence pour chacun des composants standards. Elle s'appuie sur AWT et, en pratique, on utilise AWT pour les objets qui ne s'affichent pas (événements, écouteurs, agenceurs de composants) et {{:departement_info:personnels:pb:pa3:swing.pdf|Swing}} pour les objets qui s'affichent à l'écran (fenêtres, menus et leurs éléments, boutons divers, zones de texte, curseurs...).
+Depuis 1998 avec la sortie de java 2, la bibliothèque Swing offre la possibilité de créer des interfaces indépendantes du système d’exploitation et propose plusieurs choix d'apparence pour chacun des composants standards. Elle s'appuie sur AWT et, en pratique, on utilise {{:departement_info:personnels:pb:pa3:awt.pdf|AWT}} pour les objets qui ne s'affichent pas (événements, écouteurs, agenceurs de composants) et {{:departement_info:personnels:pb:pa3:swing.pdf|Swing}} pour les objets qui s'affichent à l'écran (fenêtres, menus et leurs éléments, boutons divers, zones de texte, curseurs...).
 En 2008, Sun Microsystems à proposé une alternative à AWT+Swing, plus performante et complète (prise en charge des écrans tactiles par exemple), JavaFX. Reprise par Oracle suite au rachat de java, la bibliothèque JavaFX est intégrée au JDK depuis la version 8 en 2014 et jusqu'à la version 11 de 2018, où le projet est dissocié du JDK. C'est alors la communauté OpenJFX qui poursuit son développement. En tant que bibliothèque externe au JDK, elle est un peu moins pratique à mettre en œuvre que Swing. Notre propos étant la programmation avancée et pas le développement d'interfaces graphiques, nos applications graphiques seront développées avec Swing.