Discussion :

[weabow]

Je crée un classe qui dérive de JTextField (public class _cTextBox extends JTextField {).

Dans cette classe, je gère différents évènements.

Deux options se présentent alors :

1) dans la définition de la classe, j'utilise implements ...quelquechoseListener
2) je crée par exemple dans le constructeur un this.AddListener...

Quelle est la meilleure méthode et pourquoi ?

Christian

[joel.drigo]

Salut,

Personnellement, je préfère le petit goût de fraise des bois de la première au goût de marron prononcé de la seconde

Sérieusement, on ne peux pas comparer 2 façons d'écrire une classe en terme de "meilleure", mais en termes d'efficacité, simplicité, performance, praticabilité, possibilités (que la classe désire offrir, ou ne veut pas permettre), extensibilité, etc...

Il me semble, tout d'abord, que les deux manières ne sont pas 2 alternatives de la même chose :
1) quand une classe implémente une interface, que cela soit un "quelquechose listener", ou autre, c'est qu'elle va avoir les méthodes de l'interface, pour pouvoir se comporter comme l'interface le demande. Donc pour une interface d'écouteur d'évènement, elle va se comporter en écouteur d'évènements
2) quand une classe appelle this.addListener(..), elle appelle une de ses propres méthodes addListener(..) (qu'elle doit avoir), et donc, à priori, elle va produire des évènements. Cette façon n'empêchant pas de faire this.addListener(this), elle peut s'écouter elle-même.

Lorsque tu parles de "gérer des évènements", on ne peut pas savoir, si tu veux produire des évènements, ou faire des traitements sur évènements écoutés, ou les deux.

[joel.drigo]

public class _cTextBox extends JTextField {

En matière de conventions de nommage, tu cherches à te démarquer au maximum ou quoi ?

[weabow]

Merci de ta réponse.

Dans les deux cas, je suis obligé d'implémenter les méthodes (@override). C'est là où je ne vois pas réellement de différence dans le codage.

Par contre j'imagine bien qu'il y a un impact ailleurs.

Mon exemple :
dans ma cTextBox, je programme à l'intérieur de la classe elle-même un autoSelect de tout ce qu'il y a dans la textBox, lors du gotFocus. Dans ce cas, la classe s'écoute elle-même.

Mais cela n'empêche pas de propager les évènements vers le container, qui lui même bénéficie des méthodes ad'hoc. Ceci m'est nécessaire de capter certains évènements pour faire du contrôle de saisie.

Est-ce plus clair ?

Christian

[weabow]

Pour Joel :

Je suis preneur de considérations de nommage, avec plaisir. Un lien vers un doc, peut-être ?

Merci.

Christian

[joel.drigo]

Les noms de classes commencent par une lettre majuscule.

Lien sur les conventions java.

[joel.drigo]

Dans les deux cas, je suis obligé d'implémenter les méthodes (@override). C'est là où je ne vois pas réellement de différence dans le codage.

JTextField n'étant ni une classe abstraite ni une interface, je ne vois pas quelles méthodes tu serais obligé d'implémenter.

Mon exemple :
dans ma cTextBox, je programme à l'intérieur de la classe elle-même un autoSelect de tout ce qu'il y a dans la textBox, lors du gotFocus. Dans ce cas, la classe s'écoute elle-même.

Ok, dans ce cas, ce comportement est un comportement interne à ta classe. Donc pas de raison qu'on puisse avoir accès de l'extérieur de la classe. Donc, la classe peut s'écouter elle-même, en s'ajoutant un écouteur sur la gain de focus : après le choix entre l'écouteur sous forme de classe anonyme et classe interne se fera sur la "taille" du code nécessaire. Pour ton autoselect, il n'y a pas des masses de code (une ligne ou 2), je ferais une classe anonyme.

Mais cela n'empêche pas de propager les évènements vers le container, qui lui même bénéficie des méthodes ad'hoc. Ceci m'est nécessaire de capter certains évènements pour faire du contrôle de saisie.

Ta nouvelle classe étend JTextField, donc l'utilisateur de cette classe peut écouter les évènements de JTextField, sans que tu aies à faire quoique ce soit.
Si tu veux ajouter des nouveaux évènements à toi, c'est différent. Il te faudra créer une interface TrucListener, ajouter des méthodes addListener(TrucListener) et removeListener(TrucLIstener) dans ta classe. En t'inspirant du code d'un évènement de SWING (en utilisant une EventListenerList par exemple).
Ensuite, si tu veux modifier le comportement des évènements déjà existant sur le JTextField, c'est plus complexe parce que ça dépend tout d'abord de ce que tu veux faire exactement et que les possibilités sont infinies, ou presque.

[adiGuba]

Salut,


Pour moi la solution qui consiste à implementer les listeners dans la classe de base a un gros défaut :

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
class CTextBox extends JTextField implements ActionListener, CaretListener {
 
	public CTextBox() {
		addActionListener(this);
		addCaretListener(this);
	}
 
	@Override
	public void actionPerformed(ActionEvent e) {
		// code du listener	
	}
 
	@Override
	public void caretUpdate(CaretEvent e) {
		// code du listener
	}
}

C'est que cela "pollue" l'API de ton composant, qui devient ainsi également un ou plusieurs listeners.

Une mauvaise utilisation pourrait rajouter ton composant comme listener à un autre. Même par erreur (mauvaise proposition de code de l'EDI par exemple) :

Code :

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

1
2
3
CTextBox box = new CTextBox();
JButton button = new JButton();
button.addActionListener(box); // est-ce souhaitable ?

La seconde solution, qui consiste à utiliser des classes anonymes ne me plait pas trop non plus :

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
class CTextBox extends JTextField {	
	public CTextBox() {
		addActionListener(new ActionListener() {
			@Override
			public void actionPerformed(ActionEvent e) {
				// code du listener	
			}
		});
		addCaretListener(new CaretListener() {
			@Override
			public void caretUpdate(CaretEvent e) {
				// code du listener	
			}
		});
	}
}

Ok les listeners ne sont plus visible en dehors de la classe, mais le code en devient assez pénible à lire.
Et en plus on perd là la possibilité de redéfinir les listeners dans les classes filles...




Perso j'aime bien utiliser une classe interne private qui implémentera tous les listeners en appelant une méthode d'instance de la classe :

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
21
22
23
24
25
26
27
class CTextBox extends JTextField {
 
	public CTextBox() {
		Listeners listeners = new Listeners();
		addActionListener(listeners);
		addCaretListener(listeners);
	}
 
	protected void onActionPermformed(ActionEvent e) {
		// code du listener
	}
 
	protected void onCaretUpdate(CaretEvent e) {
		// code du listener
	}
 
	private class Listeners implements ActionListener, CaretListener {
		@Override
		public void actionPerformed(ActionEvent e) {
			onActionPermformed(e);
		}
		@Override
		public void caretUpdate(CaretEvent e) {
			onCaretUpdate(e);
		}
	}
}

Les méthodes listeners sont protected et ne sont donc pas visible de l'extérieur, mais les classes filles peuvent les redéfinir.
Et si le code est un peu plus verbeux, c'est quand même un peu plus lisible qu'une multitude de classe anonyme...






A noter toutefois qu'à partir de Java 8 les références de méthodes simplifieront encore la chose :

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
class CTextBox extends JTextField {
 
	public CTextBox() {
		addActionListener(this::onActionPermformed);
		addCaretListener(this::onCaretUpdate);
	}
 
	protected void onActionPermformed(ActionEvent e) {
		// code du listener
	}
 
	protected void onCaretUpdate(CaretEvent e) {
		// code du listener
	}
 
}

a++

[weabow]

Un grand merci pour ces explications détaillées.

Christian