Java : Modèle / Vues / Contrôleurs Cours LOO / Y.Laborde Java : Modèle / Vues / Contrôleurs LES CONCEPTS du paradigme MVC : Introduction L’implémentation MVC dans Java le package java.util la classe java.util.Observable l’interface java.util.Observer La méthode notifyObservers(Object arg) nécessité de l’argument non nul une classe de messages : WhatChanged La technique du modèle interfacé en strates dérivations successives du modèle (strates) interfaçage par strates du modèle (diapo 5) (5) (6) (7) (8) (9) (xx) Cours JAVA / Y.Laborde

Java : MVC / Introduction Le paradigme MVC (Modèle / Vues / Contrôleurs) est conçu pour les applications possédant une forte interactivité avec l’utilisateur. De fait, il est parfaitement adapté aux applicatifs dotées d’une IHM. C’est une technique de programmation basée sur le développement modulaire. En effet, toute application interactive peut a priori être découpée en 3 parties : le modèle (éventuellement architecturé en modèle principal et modèles secondaires) les vues les contrôleurs Quel sont les rôles des contrôleurs ? Quel est le rôle du modèle ? Quel sont les rôles des vues ? Son rôle est de conserver l’état des données spécifiques à l’applicatif et de réaliser les traitements algorithmiques afférents. Leur rôle est de maintenir à jour, en totalité ou en partie, une représentation (graphique) de l’état courant du modèle et de fournir l’interactivité nécessaire. Leur rôle est de définir le comportement des vues vis-à-vis des interactions (clavier, souris, …) et de les acheminer sous forme d’événements aux vues. Exemple de la calculatrice : C’est tout ce qui réalise les opérations mathématiques, les conversions, la mise en mémoire de valeurs, la vérification du parenthésage, … Exemple de la calculatrice : Ce sont tous les composants graphiques comme l’afficheur du résultat, l’afficheur de présence d’une valeur mémorisée, l’activation ou non d’une commande, … ainsi que la Frame, les boutons, … Exemple de la calculatrice : Ce sont tous les Listener mis en place : ActionListener, TextListener, WindowListener, … Cours JAVA / Y.Laborde

Java : MVC / Introduction Le concept de modularité sous-jacent à la technique MVC oblige à ce que les modules communiquent entre eux. Mise à part l’initialisation des liens à l’instanciation des modules, les communications entre modules peuvent être de plusieurs types : modèle vers vues vues vers modèle contrôleur vers vues M => *V (4) (4) M => *V : le modèle CHANGE SON ETAT INTERNE puis fait la demande à CHAQUE VUE (inscrite) de se mettre à jour pour refléter ce nouvel état. Ici, c’est principalement AfficheurRésultat qui devra modifier la valeur affichée. ModèleDeCalculatrice Modèle AfficheurRésultat Vues Bouton « + » Bouton « = » … AfficheurRésultatAdapteur BoutonsOpérationsBinairesAdapteur Composants Ecouteurs AfficheurRésultatContrôleur Contrôleurs BoutonsOpérationsBinairesContrôleur … 1V => M (3) (3) 1V => M : l’adaptateur de la vue prévient le modèle de l’interaction utilisateur 1C => 1V (2) (2) 1C => 1V : le contrôleur Java achemine le message vers l’adaptateur de vue intéressée JVM (WM) (1) (1) JVM (WM) : la JVM prévient le contrôleur Java en encapsulant un événement approprié click Cours JAVA / Y.Laborde

Java : MVC / Introduction Ainsi avec le paradigme MVC : - chaque contrôleur communique avec une vue - chaque vue communique avec un modèle (et éventuellement avec des sous-modèles) mais - le modèle communique toujours avec de nombreuses vues sans véritablement les distinguer les unes des autres. Il ne fait que les informer que son état a changé. Aux vues de se mettre à jour pour représenter correctement le nouvel état du modèle. Cela est dû à la fonction même du modèle : * protéger les données propres à l’applicatif en les encapsulant, * faire évoluer les données (sans risquer leur incohérence) à l’aide d’algo-rithmes internes « parfaitement sûrs », * informer les vues de tout changement d’état, * fournir des méthodes « sûres » permettant aux vues de connaître l’état du modèle. Il en découle tous les avantages de la modularité (réutilisabilité, maintenance aisée, développement en équipe, application à de grands projets, …). Cours JAVA / Y.Laborde

Java : MVC / le package java.util L’implémentation MVC de Java consiste à fournir DEUX entités toutes les deux implémentées dans le package « java.util ». public ModèleDeCalculatrice extends java.util.Observable Observable Observer Les entités MVC de Java Le MODELE doit dériver cette classe pour devenir OBSERVABLE par des VUES public classe Object public interface Les VUES doivent implémenter cette interface pour devenir OBSERVATRICES de MODELES public BoutonsOpérationsBinairesPanel extends java.awt.Panel implements java.util.Observer , java.awt.event.ActionListener Les CONTRÔLEURS sont « transparents » en Java. Ils sont en grande partie implémentés par la JVM. public AfficheurRésultat extends java.awt.TextField implements java.util.Observer , java.awt.event.TextListener Cours JAVA / Y.Laborde

Java : MVC / la classe java.util.Observable public class java.util.Observable extends Object Cette classe représente un modèle Observable. Elle doit être dérivée pour obtenir un modèle applicatif. Un modèle peut avoir un ou plusieurs « observateurs ». Ceux-ci devront s’inscrire auprès du modèle observable pour que celui-ci puisse leur envoyer les messages de mise à jour à chaque changement de son état. Pour cela, après qu’un Observable change d’état, il doit invoquer SetChanged() puis notifyObservers(…) pour que tous ses Observer soit notifiés du changement par l’appel de leur méthode update(…). L’ordre dans lequel les Observer sont notifiés ne fait l’objet d’aucune spécification. Object Observable CONSTRUCTEURS : public Observable () METHODES : public void addObserver (Observer o) => pour inscrire un Observer (une vue) protected void setChanged ( ) => sans appel de cette méthode, les 2 suivantes ne font rien ! public void notifyObservers ( ) => si le flag de changement est positionné, notifie TOUS les public void notifyObservers (Object arg) Observer inscrits (avec l’argument vide ou non) public boolean hasChanged ( ) => indique l’état du flag de changement du modèle Cours JAVA / Y.Laborde

Java : MVC / l’interface java.util.Observer public interface java.util.Observer Une classe peut implémenter cette interface lorsqu’elle veut être informée des changements d’un objet Observable (i.e. un modèle). Ce dernier invoquera la méthode update(…) de l’Observer à chaque fois que son état interne aura changé. Observer METHODES : public void update (Observable o, Object arg) Observable o, le modèle qui a envoyé ce message. Cela permet de retrouver le modèle dont l’état a changé de sorte à le questionner pour connaître son état. Ce paramètre peut faire l’objet d’un cast en cas de certitude sur la classe du modèle. Object arg, un paramètre objet fournit par le modèle ( méthode notifyObservers(Object arg) ) pour renseigner sur la nature du changement. Lorsque la notification par le modèle est effectuée par appel de la méthode notifyObservers() sans paramètre, cela invoque notifyObservers(null). La méthode update(Object arg) reçoit alors une référence nulle dans arg. Cours JAVA / Y.Laborde

Nécessité de l’argument non nul Java : MVC / la méthode notifyObservers(Object arg) Nécessité de l’argument non nul Cette méthode peut être utilisée lorsque l’on désire fournir des renseignements aux vues sur la nature du changement produit dans le modèle. En effet, dans le cas d’un applicatif possédant un état tel que des changements peuvent intervenir dans certaines parties et pas dans d’autres. exemple: la calculatrice montre à la fois le résultat du calcul et l’indicateur de présence d’une valeur en mémoire ; or parfois le modèle changera à cause d’un nouveau résultat à afficher et parfois à cause d’une modification de l’indicateur de mémoire. Si le modèle envoie un message notifyObservers() sans argument, chaque vue recevant ce message est invitée à rafraîchir sa représentation sans savoir si la partie de modèle qu’elle représente a véritablement changée ou non. Or, en général, le modèle n’est pas en mesure, après coup, d’informer les vues sur l’aspect qui vient de changer. Ainsi, certaines vues vont devoir se rafraîchir alors qu’elles n’en auraient pas besoin ! Cours JAVA / Y.Laborde

D’autres messages peuvent être ajoutés. Java : MVC / une classe de messages : WhatChanged Une méthode correcte consiste à construire une classe WhatChanged : contenant des messages prédéfinis et capable d’accepter tous types d’objets permettant de préciser les changements intervenus dans le modèle. class WhatChanged { // messages indiquant la nature du changement static public String WC_RESULTAT = “WC_RESULTAT”; static public String WC_IND_MEM = “WC_IND_MEM”; ... // Variables d’instance public String mess; public Object 01,02; // 03,04,… si nécessaire ! // Constructeurs utiles public WhatChanged(String _mess) { this.mess = _mess; } // O1 et 02 sont nuls public WhatChanged(String _mess, Object _01) { this.mess = _mess; this.O1 = _O1; } // 02 est nul public WhatChanged(String _mess , Object _01 ,Object _02) { this.O1 = _O1; this.O2 = _O2; } } Ici, les deux messages définis correspondent à un changement du résultat (WC_RESULTAT) et à un changement de l’indicateur de valeur en mémoire (WC_IND_MEM). D’autres messages peuvent être ajoutés. Ici, deux objets O1 et O2 permettent au modèle de transmettre des informations complexes aux vues. Mais ces dernières doivent connaître le type d’objets effectivement transmis pour pouvoir effectuer un cast et retrouver leur contenu. Cours JAVA / Y.Laborde

Java : MVC / exemple d’utilisation de WhatChanged class ModèleDeCalculatrice extends java.util.Observable { // Variables d’instance du modèle protected double result, oldResult; protected char oldOperator; protected double memoryValue; protected boolean oldResultOK, oldOperatorOK, memoryValueOK; public ModèleDeCalculatrice () { this.oldResultOK = this.oldOperatorOK = this.memoryValueOK = false; } public doBinaryOperation(char op) { if (op==‘=’ && oldResultOK && oldOperatorOK) { if (oldOperator == ‘+’ ) { oldResult = result = oldResult + result ; this.notifyAll( // Construit l’argument : new WhatChanged ( WhatChanged.WC_RESULTAT , (new Double(result)).toString() ) ); } else if (oldOperator == ‘-’ ) ... } else if (op == ‘+’) ... } protected notifyAll(Object arg) { this.SetChanged(); this.notifyObservers(arg); } class WhatChanged { ... } class AfficheurRésultat extends java.awt.TextField implements java.util.Observer, java.awt.event.TextListener { ... public AfficheurRésultat ( Observable o) { o.addObserver(this); //inscription } public void update (Observable o, Object arg) { // Réception d’un chgt du modèle WhatChanged wc; if (arg instanceof WhatChanged ){ wc = (WhatChanged)arg; if ( wc.mess.equals (WhatChanged.WC_RESULTAT) ) // Modifier l’affichage this.setText((String)wc.01); Cours JAVA / Y.Laborde

Java : MVC / Exercices Exercices: en supposant que la classe ci-dessous existe, analysez comment vous pourriez gérer l’ensemble des boutons et de l’indicateur de mémoire à l’aide du modèle. public MemoryPanel extends java.awt.Panel implements java.util.Observer , java.awt.event.ActionListener écrire le code correspondant Cours JAVA / Y.Laborde

L’importance des modèles Java : MVC / La technique du modèle interfacé en strates L’importance des modèles La construction d’un modèle est une opération des plus importante dans les applicatifs d’entreprise (importance stratégique, maintenance, développement en équipes, grande taille, …) car, en définissant les données et les algorithmes propres à l’applicatif, il renferme le cœur de l’application. Au delà, les vues doivent être également soignées mais elles sont souvent sujettes à transformations. Il est donc important de prévoir dès le départ de l’analyse une base solide permettant facilement de faire évoluer l’applicatif. Cette base doit elle-même s’appuyer sur un paradigme fort tel que celui du MVC. Or, dans cette technique modulaire de programmation, la base sur laquelle repose l’ensemble du développement n’est autre que le modèle. C’est pour cela que, dans les développement MVC, les modèles doivent correspondre aux premières préoccupations de l’analyse-conception. Cours JAVA / Y.Laborde

Dérivations successives du modèle Java : MVC / La technique du modèle interfacé en strates Dérivations successives du modèle (strates) Pour rendre un modèle à la fois plus souple et plus robuste, il peut être intéressant de le découper. Pour cela, deux techniques (non exclusives) : - le découpage en modèle principal et modèles secondaires (qui donne lieu à une hiérarchie de classes pour les modèles secondaires et où le modèle principal encapsule tous les sous modèles) - le découpage d’un même modèle en strates (où il s’agit de construire des dérivations successives d’un modèle ; chaque dérivation correspondant à un niveau supplémentaire de fonctionnalités) MODELE de base permettant de placer des fonctionnalités d’ordre générales Observable Modèle en strates Object MODELE répondant à une version élémentaire de la calculatrice sans aucune opération (afficheur du résultat + pavé numérique) abstract class ModCalcDeBase ModCalcPavéNumérique MODELE répondant à une version avec les opérations binaires ( + , - , * , / , = ) Exemple de modèle effectivement instancié. Dans ce cas, la calculatrice n’aura pas de fonctionnalité de mémoire. ModCalcOpBinaires ModCalcMemory MODELE répondant à une version avec opérations de mémorisation ( indicateur de mémoire , MC , MR , MS , M+ ) … Cours JAVA / Y.Laborde

Interfaçage par strates du modèle Java : MVC / La technique du modèle interfacé en strates Interfaçage par strates du modèle En complément, la technique peut être améliorée par la définition d’interfaces du modèle au niveau de chaque strates. Cela permettra aux vues, qui devront n’implémenter qu’une interface spécifique du modèle, de n’avoir un regard sur le modèle effectivement instancié qu’au travers d’une interface qui leur est véritablement appropriée. I_ModCalcPavéNumérique Interfaces du modèle implements Observable Modèle en strates Object ModCalcDeBase ModCalcPavéNumérique … ModCalcOpBinaires ModCalcMemory abstract class I_ModCalcOpBinaires public interface I_ModCalcOpBinaires { abstract public doBinaryOperation(char op); } I_ModCalcMemory Exemple de modèle effectivement instancié. La vue qui présente les boutons d’opérations binaires conservera une référence au modèle sous l’aspect de l’interface I_ModCalcOpBinaires. Cours JAVA / Y.Laborde

Java : MVC / Exercice Exercice: Reprenez l’analyse complète de la calculatrice en commençant par l’analyse du modèle (vous mettrez en évidence les différentes strates et interfaces du modèle). Écrivez le code correspondant. Cours JAVA / Y.Laborde