Discussion :

[dancingmad]

Bonjour,

j'ai une question un peu particulière concernant le mécanisme d'héritage en Java.

Je travaille actuellement sur l'interface graphique Swing, et j'ai besoin d'ajouter des comportements sur des composants. Pour faire ça, je déclare une classe fille d'un composant :

Code :

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

1
2
3
public class MyButton extends JButton {
 public void nouvelleMethode() {..}
}

Jusque là tout va bien.

Là où ça se corse, c'est que j'ai beaucoup de composants qui ont le même comportement (utilisent la même méthode nouvelleMethode), ce qui induis de la duplication de code...

D'où ma question : Est-il possible, sans toucher au code de Swing, de déclarer une classe MaClasse, qui implémente la fonction nouvelleMethode, et qui soit père de la classe JComponent ? Cela me permettrait d'utiliser la méthode nouvelleMethode pour la plupart des composant, sans duplication de code...

Si ce n'est pas possible (et je suppose que ça ne l'est pas), pourriez-vous m'indiquer un moyen élégant d'appliquer du comportement à tous les objets composants de Swing ?

Merci d'avance.

[bigbear19]

Salut,

Effectivement sans l'héritage multiple ça semble délicat.
Peut être que tu peux t'en sortir en utilisant un visiteur. Au niveau ajout de fonctions il me semble que c'est le pattern le plus efficace

[verbose]

J'ai été confronté à un problème similaire. J'ai essayé plusieurs architectures, et celle que j'ai finalement adopté et qui me parait la plus propre est le Decorator.

En clair, tu écris une classe qui hérite de JComponent et dans laquelle tu écris toutes les méthodes que tu veux factoriser.

Code :

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

1
2
3
4
5
6
 
public abstract class Decorator extends JComponent {
    public void methodeGenerale() {
    }
    public abstract JComponent getComponent();
}

Ensuite, tu fais hériter tes classes de composant de ton Decorator, et tu associes les sous-classes au composant Swing :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
public class MonBouton extends Decorator {
    private JButton bouton;
 
    public void methodeSpecifique() {
    }
 
    @Override
    public JButton getComponent() {
        return bouton;
    }
}

[dancingmad]

Merci pour vos réponses rapides ...

Le Décorator est certainement la meilleure solution, même si on est toujours obligé de déclarer des sous-classes pour tous les composants de Swing, ce qui n'est pas très souhaitable.

J'ai peut-être trouvé une autre piste en m'inspirant du pattern du visiteur, mais là encore, je me heurte à un problème. Voilà l'idée que j'ai eu :

On a une classe "Factory", qui définit la méthode "superMethode", avec des signatures différentes :

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 Factory {
 
 public static void nouvelleMethode(JComponent o) {
  // ...
 }
 
 public static void nouvelleMethode(JButton o) {
  // ...
 }
 
 // ...
 
}

Pour utiliser la méthode superMethode sur un Composant c, il suffit d'appeler "Factory.nouvelleMethode(c)" (au lieu de "c.nouvelleMethode()" dans l'ancienne solution).

L'idée de ce mécanisme est donc de définir un comportement de base dans la méthode qui prend en argument un JComponent, et de définir des comportements spécifiques au besoin grâce à la surcharge des méthodes.

Problème : La fonction qui appelle nouvelleMethode ne connait pas à l'avance l'instance de l'objet c, seulement le type : Component; et puisque la résolution de l'appel des méthodes se fait en fonction du type de l'objet, c'est toujours la première méthode de Factory qui est appelée !

Dans l'ancienne solution (celle où on faisait c.nouvelleMethode() ), ça marchait car la résolution de l'appel à la méthode se faisait en fonction de l'instance de l'objet...

J'aimerais donc pouvoir différencier les instances du composant c, sans faire de gros switch case avec instanceOf...

[verbose]

Il est vrai que le Decorator t'oblige à écrire autant de sous-classe que tu as de composants. Dans mon cas, cela ne posait pas de problème.

Ton architecture basée sur un "Factory" n'est pas terrible, mais si tu y tiens vraiment, tu pourrais avoir quelque chose comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
 
public interface Visitor {
    public void visit(JComponent comp);
}
public class Factory {
    public void call(JComponent comp, Visitor v) {
        v.visit(comp);
    }
}

Dans ce cas, tu devras avoir autant de Visitor concret que de traitement spécifique.

[hibour]

Je pense qu'il suffit d'utiliser l'héritage simple. Etend tes nouvelles classes de la classe qui implémente cette nouvelle méthode au lieu d'hériter de JComponent et autre..

Code :

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

1
2
3
4
5
6
7
8
9
class TaClass extends JComponent {
 protected void taNewMethod(...) {
    //...
 }
}
 
class NewClass extends TaClass /*JComponent*/ {
 //Nouvelles méthodes à implémenter
}

[dancingmad]

verbose << je ne comprend pas bien ta solution. Comment sélectionner le visiteur qui va effectuer le bon traitement sur le composant ? i.e. si on a un JComponent c, comment instancier le bon visitor v, si on ne connait pas l'instance de c à l'avance (à la compilation) ?

[tchize_]

Si tu commençais par nous expliquer quel comportement tu tente d'ajouter sur tous les composant swing que tu utilise, on pourrait t'orienter. Par exemple si ce sont des comportements d'affichage, il te sera probablement plus facile de jouer avec les LookandFeel qui sont responsable du dessin des composant et qui sont centralisés.

[verbose]

verbose << je ne comprend pas bien ta solution. Comment sélectionner le visiteur qui va effectuer le bon traitement sur le composant ? i.e. si on a un JComponent c, comment instancier le bon visitor v, si on ne connait pas l'instance de c à l'avance (à la compilation) ?

Si ton problème est d'associer un traitement à un type spécifique, je pense que le pattern Decorator est le mieux adapté.

Si tu veux absolument adopter un "Factory", tu peux faire un truc dans ce genre :

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
 
public class Factory {
    private static Map<Class<?>,Visitor> mapper;
 
    static {
        mapper.put(VisitorA.class, new VisitorA());
        mapper.put(VisitorB.class, new VisitorB());
    }
 
    public static void call(JComponent comp) {
        Visitor v = mapper.get(comp.getClass());
        if (v != null) {
            v.visit(comp);
        }
    }
}

Mais très franchement, le Decorator est plus élégant.

[dancingmad]

Mais très franchement, le Decorator est plus élégant.

En effet, la solution avec la Factory est très peu élégente, et pas du tout orientée objet... Je vais donc utiliser le pattern Decorator.

Merci pour vos réponses !