Discussion :

[mitje]

Alors voilà,

j'ai deux classe différentes A et B,
A contient des objets.
B contient les objets pair des objets que A.
Lorsque j'ajoute un objet à A j'ajoute un pair de cet objet a B
Lorsque j'ajoute un objet à B j'ajoute un pair de cet objet à A
Quant j'enlève un objet à A j'enlève le pair de cet objet dans B
Quant j'enlève un objet à B j'enlève le pair de cet objet dans A

1ere solution de conception )

J'ai une instance de A dans B et une de B dans A .
Lors de la suppression d'un objet dans B j'invoque une méthode de A qui supprime aussi cet objet dans A et vice versa.

Problème :

class A {
B b;
remove(obj) {
removeConponent(obj);
b.remove(obj);
}
}

class B {
A a;
remove (obj) {
removeConponent(obj);
a.remove(obj);
}
}

ça va boucler, il faut donc créer une méthode spéciale dans chacune classe qui est faite pour être utilisé dans l'autre classe du genre :

removedFromB() dans A qui ne fait appel qu'a removeComponent()
removedFromA() dans B idem

Deplus, cette solution technique nécéssite la création de méthode du genre
setAssociatedObjet(A a) dans B
setAssociatedObjet(B b) dans A
On ne peux pas uniquement se contentait d'un paramètre dans le constructeur du genre dans A : public A(B b);

Cette solution n'est pas trés satisfaisante, quelqu'un aurait-il une autre idée ?

[dr00w]

C'est pas mal abstrait tout ça, quelle est la relation entre A et B dans le concret ?

[mitje]

Disons que A est un JTree et que B est un TabbedPane comme dans le Jbuilder. Supposons que
- supprimer un noeud dans A entraine la fermeture d'un onglet dans B et réciproquement.
- ajouter un noeud dans l'arbre => ajouter un onglet

Du coup avec la 1ere solution :
j'ai un attribut de type B dans ma classe A qui me permet d'ajouter/supprimer un onglet à une instance de B lorque je ajoute/supprime un nouveau noeud dans un instance de A

De même j'ai un attribut de type A dans ma classe B qui me permet de supprimer un noeud dans une instance de A lorsque je supprime un onglet dans une instance de B.

Et donc cette solution ne me satisfait pas, aurais tu une autre idée ?

[herve91]

Il n'est pas nécessaire que les classes A et B se connaissent. Tu peux toujours utiliser un mécanisme de type listener pour arriver à tes fins, ce qui a l'avantage de ne pas coupler les classes : si d'aventure un jour tu as une classe C qui souhaiterait également être avertie des ajouts/suppressions dans l'arbre, il suffira qu'elle soit à l'écoute des événements correspondants.

[dr00w]

Ok, je pense que je comprend ce que tu veux faire. Prenons, par exemple, ton arbre qui contient des références à des objets. Un noeud est donc UNE des représentation graphique de l'objet A sous une forme simple : son nom. Un onglet est une AUTRE représentation graphique du même objet A sous une forme détaillée. Si on suit le même principe, pourquoi ne pas aussi ajouter un menu avec des items et dont l'un d'eux est aussi une représentation graphique de l'objet A. Va-tu aussi inclure une réference à cet item dans tes objets ? Et si après tu veux une barre d'outils ?

Tu comprends que ça va vite devenir une toile d'araignées !

Je te suggère de revoir ton design en utilisant un objet tier qui lui s'occupera de la gestion.

[mitje]

Il n'est pas nécessaire que les classes A et B se connaissent. Tu peux toujours utiliser un mécanisme de type listener pour arriver à tes fins, ce qui a l'avantage de ne pas coupler les classes : si d'aventure un jour tu as une classe C qui souhaiterait également être avertie des ajouts/suppressions dans l'arbre, il suffira qu'elle soit à l'écoute des événements correspondants.

En effet, j'ai creer une tierce classe C comportant les attributs de type Tree et TabbedPane et implementant deux interface :

TreeModelListener me permet de savoir quand un noeud est ajouter ou enlever ou éditer.

ContainerListener me permet de savoir quand un Component est enlever ou ajouter au TabbedPane.

Les attributs sont instanciés à la construction et on leur ajoute C en tant TreeModelListener pour l'arbre et en tant que ContainerListener pour le TabbedPane.

Du coup ça simplifie considérablement le modèle surtout si je veux, par exemple, rajouter des boutons qui agissent sur l'arbre ou sur les onglets.

merci hervé et merci dr00w pour vos commentaires

A+

[dr00w]

Bravo ! Tu es sur la bonne voie.

Juste une remarque en passant :

essaie de coder vers une interface plutôt que vers une implémentation. C'est là que réside toute la puissance du polymorphisme.

Ex :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// coder vers une implementation
ArrayList list;  
...
list = new ArrayList(); //pas le choix, list ne peut référer qu'à une ArrayList
 
// coder vers une interface
Collection list;
...
list = new ArrayList();
list = new LinkedList();
list = new TreeSet();
etc.

[mitje]

Bravo ! Tu es sur la bonne voie.

Juste une remarque en passant :

essaie de coder vers une interface plutôt que vers une implémentation. C'est là que réside toute la puissance du polymorphisme.

Ex :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// coder vers une implementation
ArrayList list;  
...
list = new ArrayList(); //pas le choix, list ne peut référer qu'à une ArrayList
 
// coder vers une interface
Collection list;
...
list = new ArrayList();
list = new LinkedList();
list = new TreeSet();
etc.

Que veux tu dire exactement ?

Que je devrait créer une interface C plutôt qu'une classe C

[dr00w]

Que veux tu dire exactement ?

Que je devrait créer une interface C plutôt qu'une classe C

Non, c'est dans l'autre sens : ce sont tes objets A et B qui devrait implémenter la même interface puisqu'ils sont tous les 2 des vues sur le même objet. Je te suggère de lire sur les "Design Patterns" et plus particulièrement sur MVC (Model View Controller). Dans ton cas, ton objet C serait le controlleur, A et B des vues et l'objet à représenter ton modèle.

[mitje]

Que veux tu dire exactement ?

Que je devrait créer une interface C plutôt qu'une classe C

Non, c'est dans l'autre sens : ce sont tes objets A et B qui devrait implémenter la même interface puisqu'ils sont tous les 2 des vues sur le même objet. Je te suggère de lire sur les "Design Patterns" et plus particulièrement sur MVC (Model View Controller). Dans ton cas, ton objet C serait le controlleur, A et B des vues et l'objet à représenter ton modèle.

Super la notion MVC pour concevoir les appli.
Du coup j'ai créer mon propre modèle de donnée Observable.
Pour me faciliter la tache j'ai utiliser un treemodel dans ma classe pour représenter ma donnée. Pour la représentation graphique j'ai qu'a faire un setModel dans mon JTree est le tour est jouer. Deplus, ma classe qui implémente JTree n'a pas besoin d'être Observer pour une mise à jour graphique (effectuer un changement sur le modèle suffit).
Pour le TabbedPane par contre j'ai était obligé d'implémenter Observer car je ne sais comment récupérer ni instancier le modèle de donnée d'un JTabbedPane. Sa serait vraiment pratique d'avoir un modèle comme dans JTree , du genre un Tableau de component, hop tu met à jour le tableau et l'affichage change instantement sans faire de add ou remove().
Du coup quelqu'un aurait-il une suggestion à ce sujet ?

[dr00w]

J'ai pas vraiment de suggestions pour le JTabPane. Il est rare que tu ais besoin d'un modèle élaboré pour ce type de composant puisqu'il peut contenir un nombre restraint de "pages" (afficher plus de 10-12 tabs est généralement une mauvaise idée). Rien ne t'empêches de t'en créer un en t'inspirant de l'interface ListModel mais je ne suis pas certain que s'en vaille la peine...

[mitje]

J'ai pas vraiment de suggestions pour le JTabPane. Il est rare que tu ais besoin d'un modèle élaboré pour ce type de composant puisqu'il peut contenir un nombre restraint de "pages" (afficher plus de 10-12 tabs est généralement une mauvaise idée). Rien ne t'empêches de t'en créer un en t'inspirant de l'interface ListModel mais je ne suis pas certain que s'en vaille la peine...

ce qui est étrange c'est que swing est, à ce que j'ai put lire, construit selon le principe MVC, donc on devrait pouvoir trouver un objet dans JTabbedPane qui sert de modèle de donnée. En tout cas merci pour ton aide droow.

[dr00w]

ce qui est étrange c'est que swing est, à ce que j'ai put lire, construit selon le principe MVC, donc on devrait pouvoir trouver un objet dans JTabbedPane qui sert de modèle de donnée. En tout cas merci pour ton aide droow.

JTabbedPane possède bel et bien un modèle soit le SingleSelectionModel donc le principe MVC est respecté

[mitje]

JTabbedPane possède bel et bien un modèle soit le SingleSelectionModel donc le principe MVC est respecté

ouais j'ai vu, mais tu peux pas t'en servir comme modèle de donnée, tu peux juste agir ou récupérer des infos sur la sélection des onglets.
Par exemple dans Container dont hérite TabbedPane ya une méthode :

validateTree()

cette méthode est troublante dans la mesure sont utilisation suppose l'existance d'un arbre de components (hmmm un arbre, j'aime !). Le truc c'est que ce fameux arbre tu peux pas y accéder à moins de modifier le code de Container. En plus, c'est évident qu'un arbre c'est un bon moyen de représenter une relation Contenant - Contenu ou Container - Component si tu préfère. Et si on y avait accès, plus besoin de s'emmerder avec des objets et interface du genre Oberver Observable. pour appliquer des changements garphique dues à un changement sur le modèle de données.
Je vais voir ce que donne le code de Container et voir si j'y trouve un objet du genre TreeModel et puis je vous tiens au courant.

A+

[dr00w]

ouais j'ai vu, mais tu peux pas t'en servir comme modèle de donnée, tu peux juste agir ou récupérer des infos sur la sélection des onglets.

Le modèle ne sert qu'à gèrer quel tab est sélectionné. Il y a des modifications dans la classe JTabbedPane pour Mustang permettant, entre autres, de fermer un tab avec un bouton. Je ne sais pas si c'est implémenté par contre, ni s'il possède un nouveau modèle...

[anykeyh]

Et ainsi: (A et B doivent etre dans le meme package)

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
class A {
 
B b;
protected remove(obj, boolean recursive)
{
removeConponent(obj);
if(recursive)
b.remove(obj,false);
}
 
public remove(obj)  //Methode publique
{
remove(obj, true);
}
 
}
 
class B {
 
A a;
 
 
protected remove(obj, boolean recursive)
{
removeConponent(obj);
if(recursive)
a.remove(obj,false);
}
 
public remove (obj) {
remove(obj, true);
}
 
}

En fait tu crée une seconde methode a visibilitée reduite qui verifie la recursivité. Si recursivité il y a, ta methode appelle la methode recurcive avec le parametre recurcive en faux:
De se fait, il y a au maximum 2 appels: le premier sur a et le second sur b.
Tu peu aussi mettre tes fonction en visibilitée publique, notamment si leurs classes ne sont pas dans le meme package... A toi de voir