Conseil esthétisme POO

Version imprimable

Voir 40 message(s) de cette discussion en une page

11/04/2011, 16h41
bomehc

Conseil esthétisme POO
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:

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?
11/04/2011, 16h45
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 :)
11/04/2011, 16h53
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.
11/04/2011, 17h06
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() ?
11/04/2011, 17h38
Logan Mauzaize

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

Sinon il faut utiliser un MouseListener.
11/04/2011, 17h59
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 ^^
11/04/2011, 18h11
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
11/04/2011, 18h23
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)
11/04/2011, 18h44
bomehc

Bien vu :ccool:

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...
11/04/2011, 21h22
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...
12/04/2011, 09h52
Logan Mauzaize

Ou tu ajoutes une méthode non privée à B pour ajouter un listener à J ;-)
12/04/2011, 10h32
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 ?

Un truc du genre

Code:

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:

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:

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:

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);
  }
}

12/04/2011, 12h01
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?
12/04/2011, 12h11
Pill_S

Citation:

Envoyé par bomehc

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)

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

Code:

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;
  }
}

12/04/2011, 12h30
bomehc

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

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'?

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:

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:

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 !

12/04/2011, 14h02
bomehc

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

Merci ;)
20/04/2011, 17h51
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:

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!

Voir 40 message(s) de cette discussion en une page