Discussion :

[herve91]

Bonsoir,
Supposons une classe mère abstraite Element disposant d'un certain nombre d'attributs, et dont dérivent les classes concrètes ElementA, ElementB, ElementC, chacune possédant ses attributs propres.
On souhaite représenter dans un JPanel PanelElement les caractéristiques d'un objet sous-type d'Element.
Quelle serait la façon la plus élégante et la plus "orientée objet" de définir la classe PanelElement, et éventuellement ses sous-types ?
Par exemple (toute autre suggestion est la bienvenue...) :

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
 
abstract class PanelElement extends JPanel {
  public PanelElement(Element element) {
    this.element = element;
    add(new JLabel("Date début"));
    add(new JLabel(String.valueOf(element.getDateDebut())));
    ...
  }
}
 
class PanelElementA extends PanelElement {
  public PanelElementA(ElementA elementA) {
    super(elementA);
    this.elementA = elementA;
    add(new JLabel("Heure début");
    add(new JLabel(String.valueOf(elementA.getHeureDebut())));
    ...
  }
}

Je précise que Element et ses sous-classes sont de simples business objects (beans) et qu'il n'est pas possible d'enrichir ses classes pour fournir d'autres méthodes que les getter/setter sur les attributs.
Le problème est le suivant : je dispose d'une collection d'objets de type ElementA, ElementB, ...
Comment instancier le panel correspondant en évitant des appels à instanceof ?

Code :

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

1
2
3
4
5
6
 
if (element instanceof ElementA) {
  return new PanelElementA((ElementA) element);
} else if (element instanceof ElementB) {
  ...
}

Si on est amené à créer un nouveau type ElementD, il faut prévoir son panel correspondant PanelElementD. Il est pénible d'avoir à rechercher dans le code les occurrences de instanceof ElementX pour compléter avec le nouveau type partout où c'est nécessaire...
D'où la question : y a-t-il un design pattern ou des techniques OO permettant de s'affranchir tout ou partie de faire de la reconnaissance de type à l'exécution ?

[lando]

Je ne suis pas encore vraiment au top sur les design pattern, mais le cas qui te pose problème me semble pas mal adapté à se documenter sur les factory et les décorateurs ^^.

Le concept qu'il te faudrait mettre en place est de déléguer à une classe tierce la responsabilité d'instancier le Panel adapté en fonction de l'objet courant.
L'intérêt qui se présentera assez vite c'est que dans le cas de l'ajout d'un nouveau sous-type impliquera "uniquement" la création du nouveau bean et l'introduction de la prise en charge dans la côté Factory et la création de l'objet de vue correspondant.

[Oscar Hiboux]

Effectivement, le motif Factory serait utile ici.

Autrement pour éviter les tests avec instanceof tu pourrais utiliser un tableau associatif liant des classes d'Element aux classes de Panel correspondants.

Exemple :

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 Herve91Factory
{
    private Map<Class, Class> panelsByElement;
 
    public Herve91Facrtory()
    {
        panelsByElement = new HashMap<Class, Class>();
        panelsByElement.put(ElementA.class, PanelElementA.class);
        panelsByElement.put(ElementB.class, PanelElementB.class);
        ...
    }
 
    public PanelElement createPanel(Element element)
    {
        PanelElement panel = panelsByElement.get(element.getClass()).newInstance();
        ...
    }
 
    ...
 
}

[herve91]

Merci pour vos réponses, effectivement j'ai pensé à faire un tableau associatif, mais la solution que tu proposes TigRoO° ne fonctionne pas. En effet, si tu as bien regardé les constructeurs des classes PanelElementX, elles prennent en entrée un objet de type ElementX, donc il n'y a pas de constructeur par défaut.

Voici ce à quoi j'ai pensé :

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
public class Herve91Factory {
    interface PanelFactory {
      PanelElement newInstance(Element element);
    }

    static class PanelAFactory implements PanelFactory {
       public PanelElement newInstance(Element element) {
          return new PanelElementA((ElementA) element);
       }
    }
    ...

    private Map<Class, PanelElementFactory> panelsByElement;

    public Herve91Factory()
    {
        panelsByElement = new HashMap<Class, PanelElementFactory>();
        panelsByElement.put(ElementA.class, new PanelAFactory());
        panelsByElement.put(ElementB.class, new PanelBFactory());
        ...
    }
 
    public PanelElement createPanel(Element element)
    {
        PanelElement panel = ((PanelElementFactory) panelsByElement.get(element.getClass())).newInstance(element);
        ...
    }
}

On a évité les tests avec instanceof, mais il y a toujours une conversion de type... bonne nouvelle quand même, elle est "encapsulée"...
Si qq voit une solution encore plus générique

[sinok]

Sinon en poussant plus loin dans la réflexion tu peux récupérer les Constructors de tes classes et instancier ta classe à partir de ceux ci

[herve91]

Oui, je sais, mais je trouve dommage d'utiliser des mécanismes aussi lourds que la réflexion pour faire ça... SI on en arrive là, il me semble que ça traduit quand même une limite au concept d'héritage, non ?