Télécharger la présentation
1
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 6) (6) (7) (8) (9) (10) (14) (15) Cours JAVA / Y.Laborde
2
Exemple d’une calculatrice simple.
Java : MVC / Exemple de base Exemple d’une calculatrice simple. Cette calculatrice contient différentes fonctionnalités qui peuvent être regroupées par catégories : l’afficheur du résultat les boutons de commandes ( Retour arrière, CE, C ) les boutons de mémoires ( MC, MR, MS, M+ ) la zone d’indication de présence d’une donnée en mémoire les boutons numériques ( 0 à 9, +/-, . ) les boutons d’opérations binaires ( /, *, -, + ) les boutons d’opérations unaires ( Rac, %, 1/x, = ) Cours JAVA / Y.Laborde Cours JAVA / Y.Laborde
3
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
4
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èle ModèleDeCalculatrice 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
5
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
6
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
7
Java : MVC / la classe java.util.Observable
Cours LOO / 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
8
Java : MVC / l’interface java.util.Observer
Cours LOO / 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
9
Nécessité de l’argument non nul
Cours LOO / Y.Laborde 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
10
D’autres messages peuvent être ajoutés.
Cours LOO / Y.Laborde 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
11
Java : MVC / exemple d’utilisation de WhatChanged
Cours LOO / 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
12
Java : MVC / Exercices Exercices:
Cours LOO / 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 class MemoryPanel extends java.awt.Panel implements java.util.Observer , java.awt.event.ActionListener écrire le code correspondant Cours JAVA / Y.Laborde
13
L’importance des modèles
Cours LOO / Y.Laborde 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 importantes 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éveloppements MVC, les modèles doivent correspondre aux premières préoccupations de l’analyse-conception. Cours JAVA / Y.Laborde
14
Java : MVC / Exercice Exercice:
Cours LOO / 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
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.