Discussion :

[bomehc]

Bonjour,

En Java, en général, il parait qu'il vaut mieux privilégier une variable private avec son geter et son seter par rapport à une variable public accessible par monObjet.maVariable

Cependant, si j'ai un panel A qui contient un panel B qui contient des boutons J, K, L, etc...

Si je veux que A réagisse au clic sur l'un des boutons de B, comment faire autrement que de déclarer mes boutons public et faire dans A :

Code :

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

1
2
3
4
 
ActionPerformed(ActionEvent e) {
    if(e.getSource() == B.J)...
}

?

Je ne vais pas m'amuser à faire un geter et un seter par bouton. Si?

[Logan Mauzaize]

Les boutons sont associés à des actions qui ont un nom. Idem tu peux associer un nom à un composant Swing.

Sinon utilise plusieurs listeners plutôt qu'un seul listener qui écoute tous les clics de ton application

[Pill_S]

définir des "Actions" est mieux

étendre AbstractAction et faire:

moncomposantSwing.setAction(monAction);

du coup, il prend tous les bons libellés, les bonnes icônes, etc.

[bomehc]

Pas mal ! ^^

Bon, je perçois l'idée générale, mais j'ai un peu du mal à voir comment le faire concrètement.

lorsque je crée mon bouton, j'ajoute setActionCommand("monNomDAction"), ce qui me permet d'identifier l'action par une String plutôt que par le bouton lui-même. j'ai bon?

Mais alors, maintenant, nouveau problème : j'ai besoin de savoir si mon bouton est enfoncé ou non. Par quoi remplacer mon B.J.isSelected() ?

[Logan Mauzaize]

actionPerformed est normalement appelé quand le bouton principale a été relâché au dessus du bouton.

Sinon il faut utiliser un MouseListener.

[bomehc]

Désolé, j'ai pas précisé : j'utilise un JToggleButton

Du coup, mon problème c'est que dans la classe A, j'ai besoin de connaitre l'état du bouton. Avant, j'utilisais B.J.isSelected();
Mais si J est private, ça marche pu ^^

[Logan Mauzaize]

T'as le choix entre

1. Tu sais que ta source est de type "toggle" donc tu cast.
2. Tu mets un property listener sur "selected"
3. Tu mets un item listener

[Pill_S]

sinon, passe la référence au JToggleButton en paramètre lors de la construction de l'action (du coup, l'action pourra intéroger l'état du bouton lorsque cela sera nécessaire)

[bomehc]

Bien vu

Merci

Dernier problème : je veux que A écoute J. avant j'avais dans le constructeur de A :
B.J.addActionListener(this);

mais maintenant, J est privé et je ne sais pas trop comment faire le lien entre A et J...

[bomehc]

Bon, je vois bien la solution de passer un objet de la classe A en paramètre de B, genre :

dans classe A : new B(this);
dans classe B : J.addActionLIstener(A);

mais bon, ça me parait assez moche comme code...

[Logan Mauzaize]

Ou tu ajoutes une méthode non privée à B pour ajouter un listener à J ;-)

[bomehc]

Ben oui, mais si je fais ça, je vais mettre dans B J.addActionListener(???)
Que mettre à la place des ??? pour que ce soit A qui écoute?

Merci

Au fait, pourquoi c'est pas bien les variables publiques en Java? Quel est l'avantage d'un objet privé avec son getter et son setter par rapport à un objet public ?

[Logan Mauzaize]

Un truc du genre

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
public class B
{
  public void addActionListenerToJ(ActionListener listener)
  {
    J.addActionListener(listener);
  }
  public void removeActionListenerToJ(ActionListener listener)
  {
    J.removeActionListener(listener);
  }
}

Le principal intérêt s'appelle l'encapsulation : le maintien des méthodes public et l'ajout de fonctionnalité.
Par exemple :

Code :

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

1
2
3
4
5
6
7
 
public class FooBar
{
  private int value;
  public int getValue() { return value; }
  public void setValue(int newValue) { value = newValue; }
}

Peut devenir avec le temps:
Version 1

Code :

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

1
2
3
4
5
6
7
 
public class FooBar
{
  private Integer value;
  public int getValue() { return value != null ? value.intValue() : 0; }
  public void setValue(int newValue) { value = Integer.valueOf(newValue); }
}

Version 2

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
 
public class FooBar
{
  public static String PROPERTY_VALUE = "value";
  private PropertyChangeSupport support = new PropertyChangeSupport(this);
  private int value;
  public int getValue()
  {
    return value;
  }
  public void setValue(int newValue)
  {
    int oldValue = value;
    value = newValue;
    support.firePropertyChange(PROPERTY_VALUE, oldValue, newValue);
  }
  public void addPropertyChangeListener(String property, PropertyChangeListener listener)
  {
    support.addPropertyChangeListener(property, listener);
  }
  public void removePropertyChangeListener(String property, PropertyChangeListener listener)
  {
    support.removePropertyChangeListener(property, listener);
  }
  public void addPropertyChangeListener(PropertyChangeListener listener)
  {
    support.addPropertyChangeListener(istener);
  }
  public void removePropertyChangeListener(PropertyChangeListener listener)
  {
    support.removePropertyChangeListener(listener);
  }
}

[bomehc]

Merci pour ta réponse. Je vois à peu près.

En gros, avec les setters et les getters, on peut créer différentes façon de modifier la variable, ou différentes façon de la récupérer, et même d'exécuter les changements qui découlent de cette modification. C'est ça?

Bon, cette fois, vraiment dernière question (j'espère) : quel mal y-aurait-il à déclarer public la plupart de ses variables? Comme ça on y aurait accès au choix par les setters, ou par le nom de la variable directement. Non?

[Pill_S]

Bon, cette fois, vraiment dernière question (j'espère) : quel mal y-aurait-il à déclarer public la plupart de ses variables? Comme ça on y aurait accès au choix par les setters, ou par le nom de la variable directement. Non?

tu perdrais tous les bénéfices des get/set: une variable public non final est obligatoirement accessible par tout le monde en lecture ET écriture, sans possibilité de tracer les accès ni d'implémenter un contrôle d'intégrité (donc pas cool)

[Logan Mauzaize]

On perd également la possibilité de faire du Lazy Loading.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class B
{
  private Object j = null;
 
  public Object getJ()
  {
    if (j == null)
    {
      j = new Object();
    }
    return j;
  }
}

[bomehc]

Ah, je vois. J'arrivais pas à comprendre exactement. Merci !

Bon, du coup j'ai encore une question (désolé pour mes bonnes résolutions, envolées à peine 10 minutes après les avoir prises) :

Est-ce que c'est "propre" de créer une classe static chargée de faire le lien entre deux component trop "éloignés" l'un de l'autre ?

Par exemple, si A contient B qui contient C et A contient aussi B' qui contient C', est-ce une bonne idée de créer une classe static ayant les références de C et C' et qui permette de créer facilement un "listening" entre C et C'?

[Logan Mauzaize]

En général on limite l'utilisation des champs static car (presque) n'importe qu'elle instance y a accès, la même référence est partagée par tout le monde (donc tout le monde est impacté), la mémoire ne peut pas être libérée.

Dans le cadre d'une IHM, tout le code fonctionne en "bloc" et la "cohérence" est nécessairement maintenue. Donc casser quelques règles de bonne pratique ne me choque pas, mais il faut pas que ca se généralise au sein du code de l'IHM et encore moins au reste du code ainsi que les autres projets.

La solution pour toi serait plutôt de créer un repository.

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
 
public class GuiRepository
{
  private Map<String, JComponent> components = new HashMap<String, JComponent();
  public void addComponent(String key, JComponent component)
  {
    return components.get(key);
  }
  public JComponent removeComponent(String key)
  {
    return components.remove(key);
  }
  public JComponent getComponent(String key)
  {
    return components.get(key);
  }
  public Set<Entry<String, JComponent> getComponentEntries()
  {
   return components.entrySet();
  }
}

Ensuite soit tu en fais un singleton :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public class GuiRepository
{
  private static GuiRepository SINGLETON = null;
  public static GuiRepository getInstance()
  {
    if (SINGLETON == null)
    {
      SINGLETON = new GuiRepository();
    }
    return SINGLETON;
  }
}

Soit tu créée une nouvelle instance de cette classe que tu passe en paramètre aux différents objets. L'utilisation d'une instance plutôt qu'un singleton te permet de contrôler qui accède à quoi !

[bomehc]

Je vois! Je connaissais pas du tout.
Ca m'a l'air parfait pour régler mon problème.

Merci

[bomehc]

Bon, désolé de ressortir les vieux topics, mais j'arrive pas à savoir comment mettre en place la solution proposée par Nemek.

Est-ce que le repository est sensé permettre de faire les ponts entre les objets? (genre, dans mon dernier exmple, C récupère C' grace au répository et l'écoute)

Ou alors est-ce que le repository va écouter tout le monde et transmettre à chacun ce qu'il a besoin de savoir.
J'imagine que les deux marchent, mais je sais pas ce qui est le plus "propre"?

Dans le même style, l'utilisation du repository m'oblige à avoir des choses du style :

Code :

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

1
2
 
((maClasse)GUIRepository.getInstance().getComponent("nomObjetMaClass")).maMethodeDésirée();

et encore, dans les cas simples. Ca me parait lourd, non? Y a des méthodes pour alléger?

Merci!