Discussion :

[arsenik7]

Bnojour , je me demande si il est préférable de declarer un actionListener par bouton ou un pour tous avec des if ?

merci

[ Sujet déplacé depuis le forum java par Viena ]
Les Règles du Forum

[Oui-Oui MB]

Ca dépend... Si tu as 2 ou 3 boutons, un même actionListener s'en sort bien mais si tu as 50 boutons, vaut mieux faire des groupes d'actionListener...

Sinon, tu peux aussi faire des méthodes qui porte le nom de performXXX ou XXXExecute où XXX correspond au nom du bouton. Ainsi, dans ton actionListener, tu récupères le nom du bouton et par la réflexivité, tu appelles la méthode qu'il faut.

[Mathieu.Nanoux]

moi, je ferai un par bouton.

1. C'est plus facile pour s'y retrouver après dans le code.
2. Je pense que l'instruction if est plus lourd que si tu appelle directement la métode actionListener correspondant au bouton.

[xavlours]

Je dirais que ca dépend de ce que fait le bouton.
Si il doit interagir avec 10 sous composants et 20 sous sous composants, ca va etre lourd de faire un actionlistener par bouton (références croisées, à mettre à jour, ...). Alors qu'un seul actionlistener dans le conteneur général suffit.

Ca dépend surtout de ton style de programmation. Je te conseille ma méthode habituelle, et je pense que lemccain aussi.

[Pill_S]

Oui-Oui MB: concernant les performances, tu ne pourras jamais égaler des suites de "if" en utilisant la réflexivité, c'est beaucoup trop coûteux

[Ofunk]

tu peux utiliser aussi des interfaces javax.swing.Action moi je trouve ça plus joli

[arsenik7]

J'ai environ 20 boutons.

Mais je m'mmele les pinceaux avec sans utilisé de if dans un actionlistener.

Regargez plutôt :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
import java.awt.Color;
import java.awt.Container;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
 
import javax.swing.BorderFactory;
import javax.swing.JButton;
import javax.swing.JPanel;
 
 
 
public class Legende extends JPanel implements ActionListener{
 
	String name;
	Plan plan;
	JButton[] label;
 
	public Legende(int largeur, int hauteur, Plan plan)
	{	
		this.plan=plan;
 
		this.setBorder(BorderFactory.createLineBorder(Color.black,2));
		this.setLayout(null);
 
		JButton b1 = new JButton("ALARMES");
		JButton b2 = new JButton("SORTIE");
		JButton b3 = new JButton("AGRANDIR");
 
		label = new JButton[19];
		label[0]=new JButton("Siège SGSF");
		label[1]=new JButton("Locaux divers");
		label[2]=new JButton("Latéraux");
		label[3]=new JButton("SAP");
		label[4]=new JButton("MCV1000");
		label[5]=new JButton("Lunettes chauffantes");
		label[6]=new JButton("CDI Sud");
		label[7]=new JButton("Zone K");
		label[8]=new JButton("Bureaux auto");
		label[9]=new  JButton("Achats SGGF");
		label[10]=new JButton("Stock auto");
		label[11]=new JButton("Feuilleté");
		label[12]=new JButton("Magasin Verre");
		label[13]=new JButton("MCV2000 & 3000");
		label[14]=new JButton("Embalage");
		label[15]=new JButton("Découpe travers");
		label[16]=new JButton("Equarri");
		label[17]=new JButton("Float");
		label[18]=new JButton("Four");
 
		for(int i=0;i<19;i++)
		{
			label[i].setBounds(10,400+15*i,200,20);
			this.add(label[i]);
			label[i].addActionListener(this);
 
		}	
 
		b1.setBounds(1,1,200,50);
		b2.setBounds(1,50,200,50);
		b3.setBounds(1,200,200,50);
 
		this.add(b1);
		this.add(b2);
		this.add(b3);
 
		b1.addActionListener(this);
		b2.addActionListener(this);
		b3.addActionListener(this);
 
	}
 
 
		public void actionPerformed(ActionEvent e)
		{
			int bouton = e.getID();
			System.out.println(bouton);
		}
 
 
		public void actionPerformedb1(ActionEvent e) {
			String type = e.getActionCommand(); //retourne la valeur du boutton		
			plan.Afficher_alarmes();
			plan.repaint();
		}
 
		public void actionPerformedb2(ActionEvent e) {
			System.exit(0);
		}
 
		public void actionPerformedb3(ActionEvent e) {
			String type = e.getActionCommand(); //retourne la valeur du boutton		
			//methode
			plan.repaint();
		}
 
 
 
}

20 boutons, est-ce enorme avec des if ? si ca passe , je voudrai bien quand meme que l'on me montre un code avec plusieurs boutons et un actionlistener sur chacun ...

[Pill_S]

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
28
29
30
31
32
33
34
35
 
class Toto extends JFrame implements ActionListener{
  ...
  private JButton getButton1(){
    if(button1==null){
      button1 = new JButton("OK");
      button1.addActionListener(this);
    }
 
    return button1;
  }
 
  private JButton getButton2(){
    if(button2==null){
      button2 = new JButton("Cancel");
      button2.addActionListener(this);
    }
 
    return button2;
  }
 
  ...
 
  public void actionPerformed(ActionEvent ae){
    Object source = ae.getSource();
 
    if (source == getButton1()) {
      ...
    } else if (source == getButton2()) {
      ...
    } else {
      ...
    }
  }
}

[Alec6]

La question de rapidité n'est pas trop à prendre en compte.

L'interet est plus architectural. Imagine une façade de bouton pour une lecteur de cassette de voiture. La facade peut etre retirer, voir modifiée facilement, car une broche relie l'IHM au controleur.

De faire venir tout tes évènements sur un meme goulot te permet un meilleur controle, et un meilleur découplage.

Par exemple tu peux vouloir modifier l'état de certains boutons si on clique sur qq chose (à l'exemple: quand tu fais éjecte, le bouton play remonte).

A partir de ce goulot tu peux rediriger vers des commandes. Le code est plus maintenable.

Java permet d'associer une commande (action), c'est le pattern commande, à des objets graphiques. Personellement je n'aime pas.

Bonne continuation.

[arsenik7]

MErci pour ces explications les mecs !

[clemi]

Pour completer ce que dit Alec6,

c'est une question de besoin et de style de programmation.
Le design Pattern Command permet (comme presque ts les design patterns) de decouper un code lourd en plusieurs bouts de code plus legers, de plus l'extensibilité est plus commode (rajout de commande a chaque fois).

En ce qui concerne le "tout factoriser dans un code", il a les avantages precedemment cités, mais il ne faut pas tomber dans l'anti patron "objet divin" (celui qui fait tout).

Donc il faut voir en fonction des besoins.