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?

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 :)

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.

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() ?

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

Sinon il faut utiliser un MouseListener.

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 ^^

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

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)

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...

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...

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

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

---

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?

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

---

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 !

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

Merci ;)

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!

Le repository n'est qu'une idée tu peux le gérer différemment.

soit une version plus générique qui fera éventuellement des cast implicite

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

public class Repository<T> { private Map<String, T> components = new HashMap<String, T>(); public void addComponent(String key, T component) { components.put(key, component); } public T removeComponent(String key) { return components.remove(key); } public <C extends T> C getComponent(Class<C>, String key) { return (C) components.get(key); } public T getComponentString key) { return components.get(key); } public Set<Entry<String, T> getComponentEntries() { return components.entrySet(); } }

---

Ce qui donnerait pour ton exemple

Code:

---

1 2	GUIRepository.getInstance().getComponent(MaClasse.class, "nomObjetMaClass").maMethodeDésirée();

---

soit une version sans cast:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class Repository { private Object a; private Object b; public Object getA() { return a; } public void setA(Object newA) { a = newA; } public Object getB() { return b; } public void setB(Object newB) { b= newB; } }

---

Ca dépend de tes besoins, l'un est générique l'autre est spécifique.

Le repository permet de stocker un ensemble de variable dans un espace commun. C'est pratique pour éviter de passer 999 paramètres à tes méthodes/constructeurs, mais ça fait aucun pont entre les objets.

OK, merci.

En fait, j'ai une interface composite avec des boutons qui sont dans des components très éloignés des éléments sur lesquels portent leur effet. Du coup, le Repository m'a bien aidé.

Comme je connais exactement les éléments de mon interface, j'ai privilégié ta deuxième solution.

Merci en tout cas