Discussion :

[RomG7]

Bonjour à tous,

Je souhaite réaliser une application suivant la méthode MVC. Pour commencer j'ai créé une JFRAME avec un modèle, une vue et un contrôleur. Le contrôleur de cette JFRAME fera office du contrôleur frontal ou super contrôleur.

A l'intérieur de cette fenêtre il y aura le JPANEL que l'utilisateur aura choisi d'afficher par l'intermédiaire de la barre de menu.

Bref, chaque JPANEL est développez suivant la même norme, avec un modèle une vue et contrôleur. Comme le contrôleur doit le moins possible être dépendant de Swing, j'ai créé une classe abstraite représentant la vue du JPANEL. J'ai aussi développé une classe abstraite représentant le contrôleur du JPANEL pour faciliter la manipulation depuis le contrôleur frontal de la JFRAME.

Voila pour le topo, mais j'ai un petit problème dans la conception de ces classes abstraites. Voici le code des classes abstraites :

classe abstraite représentant la vue du JPANEL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public abstract class AbstractPanel extends JPanel {
	protected AbstractControl control;
 
	public AbstractPanel(AbstractControl control) {
		super();
 
		this.control =  control;
	}
 
	public AbstractControl getControl() {
		return control;
	}
}

classe abstraite représentant le contrôleur du JPANEL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public abstract class AbstractControl {
	protected AbstractPanel view;
 
 
	public AbstractControl(AbstractPanel view) {
		super();
 
		this.view = view;
	}
 
	public AbstractPanel getView() {
		return view;
	}
 
	public abstract void refreshView();
 
	public abstract void serviceChanged(TblService service);
 
	public abstract void dateChanged(Date dateJour);
}

Maintenant je vais vous donner le code du contrôleur d'un des nombreux JPANEL qui hérite de la classe abstraite AbstractControl :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class ControlAccueil extends AbstractControl{
 
	public ControlAccueil() {
                // ici erreur a la compilation
                // cannot refer to this while explicitly invoking a constructor
		super(new ViewAccueil(this));
	}
 
	@Override
	public void refreshView() {}
 
	@Override
	public void serviceChanged(TblService service) {}
 
	@Override
	public void dateChanged(Date dateJour) {}
 
}

Il y a un problème au niveau du constructeur de cette classe, boucle sans fin. En effet, je voudrais que le contrôleur créé une instance de sa vue en lui donnant sa référence en paramètre. Je pense comprendre pourquoi cela ne fonctionne pas, mais je n'arrive pas à trouver une solution pour palier à se problème.

Merci pour votre aide

[Deaf]

Bonjour,

de manière générale, je préfère éviter le plus possible les double références explicites : A connaît B qui connaît A...
Je ne me l'autorise que lorsque deux objets sont très fortement liés.
Là, ce n'est pas le cas à mon sens.

MVC c'est très joli sur le papier, mais on découvre plein de petits détails lorsque l'on essaie de l'appliquer. Pour Swing, j'initialise très souvent de la manière suivante:

1. Création du modèle
2. Création de la vue et lien de la vue avec le modèle (via le constructeur ou par un setter)
3. Création du contrôleur et lien du contrôleur avec le modèle (via le constructeur ou par un setter)
4. Ajout de listener(s) sur la vue (= lien de la vue avec le contrôleur)

Il existe d'autres façons de faire, tu peux très bien l'adapter. Elle a le mérite de fonctionner et de garder les délimitations.

Autre remarque : en héritant AbstractPanel de JPanel, tu ne caches absolument pas Swing. En effet, tu ne peux pas passer à une autre solution (SWT par exemple) sans modifier ton contrôleur puisque l'héritage de JPanel sera toujours là. Pour t'abstraire réellement de Swing, il faudrait que tu passes par des interfaces. Il faudra aussi que tu t'abstiennes d'implémenter les listeners AWT/Swing avec tes contrôleurs et que tu fasses des classes intermédiaires. Tu auras également le problème des modèles : tu ne pourras pas utiliser les modèles Swing (TableModel, TreeModel, etc.) directement.

Il faudra peut-être voir si tu souhaites réellement t'abstraire de Swing, sinon, autant ne pas se prendre la tête avec des couches supplémentaires.

En général, je fais d'un côté ma partie métier, indépendant de toute interface et de l'autre une interface qui assume à 100% le choix de l'interface (Swing, console ou autre).

[RomG7]

Pour commencer, je tenais à te remercier pour cette réponse claire et précise. Je souhaite vraiment réaliser ce type d'architecture mais j'ai conscience que le sujet est délicat et complexe.

J'ai réussi à corriger mon problème de compilation en ajoutant un setter de la vue dans la classe abstraite du contrôleur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public abstract class AbstractControl {
	protected AbstractPanel view;
 
	public void setView(AbstractPanel view) {
		this.view = view;
	}
 
	public AbstractPanel getView() {
		return view;
	}
 
	public abstract void serviceChanged(TblService service);
 
	public abstract void dateChanged(Date dateJour);
}

Je me pose beaucoup de questions sur les réponses que tu m'as donné

de manière générale, je préfère éviter le plus possible les double références explicites : A connaît B qui connaît A...
Je ne me l'autorise que lorsque deux objets sont très fortement liés.
Là, ce n'est pas le cas à mon sens.

Je comprends mais dans mon cas le contrôleur doit bien connaître la vue pour l'initialiser et la vue doit bien connaitre le contrôleur pour appeler ses méthodes sur évènement?

Autre remarque : en héritant AbstractPanel de JPanel, tu ne caches absolument pas Swing.

Oui effectivement, je ne sais pas comment résoudre ce problème car l'héritage multiple est impossible en Java. Je pourrai passer par des interfaces mais je ne pourrai plus écrire des méthodes communes à toutes les vues?

Tu auras également le problème des modèles : tu ne pourras pas utiliser les modèles Swing (TableModel, TreeModel, etc.) directement.

Je me suis posé cette question, je pensai mettre le modèle TableModel ou AbstractListModel dans le contrôleur pour que celui ci puisse modifier le modèle qui se chargera quand à lui d'avertir la vue. Mais la aussi je crée une dépendance avec SWING. Tout celà est compliqué, comment faire?

Il faudra peut-être voir si tu souhaites réellement t'abstraire de Swing, sinon, autant ne pas se prendre la tête avec des couches supplémentaires.

En général, je fais d'un côté ma partie métier, indépendant de toute interface et de l'autre une interface qui assume à 100% le choix de l'interface (Swing, console ou autre).

Il est donc préférable de séparer d'un coté le modèle et de l'autre regrouper le contrôleur et la vue dans une classe unique (M-VC) pour éviter tous ces problèmes?
Je souhaitai vraiment séparer ces 3 couches à tort ou à raison en me disant que si je souhaitai (ré)écrire le code en PHP ou en J2EE, que l'architecture du programme serait sensiblement la même.