Principes

Dans le cadre du développement d'une application graphique, le principe du paradigme Modèle/Vue/Contrôleur (=MVC) est de séparer les données, leur manipulation et leur visualisation dans des classes différentes. Pour caricaturer :

• le modèle représente les données que l'application utilise. Il ne connaît ni la vue, ni le contrôleur.
• la vue est la représentation graphique de ces données à l'écran. Elle "écoute" les modifications du modèle pour se modifier elle-même. Elle ne connaît donc que le modèle.
• le contrôleur est la partie qui va lire/modifier le modèle en fonction des interactions de l'utilisateur avec la vue. Il n'a donc besoin de connaître que le modèle.

<aside> ☝ Ainsi, le modèle n'a pas à connaître la façon dont il est représenté à l'écran. On peut même le représenter facilement avec différente vue. Par exemple, un tableau à deux dimensions peut être visualisé sous forme de tables, camemberts, histogrammes, ... sans pour autant que sa structure soit adaptée à chaque cas.

</aside>

L'objectif du paradigme MVC est de pouvoir développer les trois parties en parallèle. Pour cela, avant tout codage, il  est nécessaire de :

• définir l'ensemble des méthodes permettant de lire/modifier les données du modèle,
• définir l'ensemble des composants graphiques permettant d'afficher le modèle à l'écran et d'interagir avec l'utilisateur,
• définir l'ensemble des méthodes qui permettent de modifier l'état de la vue.

A noter que le troisième ensemble peut être vide mais généralement, il contient des méthodes qui permettent d'invalider tel ou tel composant en fonction du traitement que l'on fait, de (de)sélectionner des cases, de masquer/afficher une fenêtre, ... Cet ensemble dépend donc fortement des besoins de l'application et de ce fait, est parfois difficile à définir.

En Java

<aside> 🥵 Malheureusement, il est très difficile d'utiliser de manière stricte ce paradigme en Java.

</aside>

Par exemple, une vue peut utiliser plusieurs composants graphiques générant le même type d'évènements. En mode strict, cela impose de créer autant de contrôleur que de composants, donc énormément de classes.

Autre problème, si une partie de la vue doit être mise à jour en fonction de modifications dans le modèle (par exemple, une case à cocher qui devient invalide), c'est à la vue de le "détecter" puisque ni le modèle, ni le contrôleur n'ont accès à la vue. Cette "détection" est complexe à mettre en place puisqu'il faut que le modèle signale qu'une donnée a été modifiée et que la vue soit à l'écoute de ce signal.

En conclusion, il convient d'utiliser un paradigme moins strict en permettant au contrôleur d'accéder à la vue. Il pourra ainsi :

• identifier la source d'évènements et donc gérer plusieurs composants émettant ce type d'évènement,
• appeler directement des méthodes de la vue, afin de modifier celle-ci lorsque les traitements l'imposent.

Dans ces conditions, le nombre de classes reste raisonnable. Généralement, cela donne :

• une ou plusieurs classes représentant la partie Modèle,