Problème Conception liste objets

Bonjour,

Petit problème de conception :

Une classe "Element" contient en attribut une liste de sous éléments qui héritent d'une interface ISousElement.
On a donc dans la classe Element l'attribut :
private List<ISousElement> liste = new ArrayList<ISousElement>();
Des classes diverses héritent de ISousElement : SousElement1, SousElement2, etc...

Ceci est résumé dans l'image ci dessous :
http://www.developpez.net/forums/att...1&d=1271842539

Vient le problème :
Certains Viewers sont dédiés à la visualisation de SousElement1.
D'autres Viewers sont dédiés à la visualisation de SousElement2.

Je dois donc dans chacun des Viewer êtes capable de récupérer une liste filtrée.
- Dois-je dans mon Viewer passer par un instanceof pour filtrer mes données d'entrée ?
- Faut il créer plutôt une méthode getList(Class class) qui permettrait de récupérer uniquement les instances du vecteur de la classe indiquée ?
- Faut-il en fait avoir 2 listes dans Element, une pour SousElement1, l'autre pour SousElement2 ?
- Ma conception est elle mauvaise ?

Comment faire pour que ma conception soit propre et modulaire ?

Merci d'avance !

Bonjour,

Le problème, ici, c'est que tes viewers sont dédiés à l'affichage d'un 'SousElement', donc d'un type concret. Je te conseille de te pencher de ce côté là, à moins qu'il y ait une raison bien précise.

As tu besoin de récupérer une liste par type de SousElement ?
Si oui le mieux est certainement de créer autant de listes que de SousElement, les unifier au sein d'une seule et même liste ne présente pas d'avantages.
Maintenant, si tu as seulement besoin de trouver le bon Viewer pour un SousElement, tu peux procéder ainsi :

Code:

---

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

private final static Map<Class<? extends ISousElement>, Class<? extends IViewer>> viewerFactories = new HashMap<Class<? extends ISousElement>, Class<? extends IViewer>>();   static { viewerFactories.put(SousElement1.class, Viewer1.class); viewerFactories.put(SousElement2.class, Viewer2.class); }   public IViewer getViewer(ISousElement se) { IViewer viewer = null; try { viewer = viewerFactories.get(se.getClass()).newInstance(); } catch (InstantiationException e) { // ... } catch (IllegalAccessException e) { // ... } return viewer; }

---

Merci pour vos réponses !

Super herve51 l'idée de mapper les types d'objets à un viewer !
C'est très élégant ! Mais dans mon cas, le viewer dois plutôt afficher une sous liste d'éléments. Je précise un peu plus mon cas :
- certains viewers affichent la liste de tous les SousElements
- certains viewers uniquement la liste des SousElement1
- certains viewers uniquement la liste des SousElement2

C'est pour cela que j'ai fait le choix d'une liste unique et non d'une liste par type de SousElement. Je me suis aussi dit que ce serait plus facilement extensible. Or dans mon cas, je souhaiterais pouvoir étendre l'application par des SousElement3, SousElement4 via des "Plugins". D'où l'idée d'une liste unique. Mais je me trompe peut être !

Donc faut-il mieux que j'effectue le filtrage :
- Dans la classe Element, via une méthode getSousElementList(Classe classe) qui récupère une liste filtrée
- Un filtrage dans le viewer via des instanceof (il me semble que c'est déconseillé d'utiliser l'instanceof)
- Faut-il en fait avoir 2 listes dans Element, une pour SousElement1, l'autre pour SousElement2 ? (--> Problème d'évolutivité ?)
- Autre ?

Bonjour, je conseillerai plutôt d'utiliser le pattern visiteur pour faire ce que tu veux :

Dans l'interface ISousElement, tu ajoutes une méthode
boolean isSupportedByViewer(IViewer viewer)

Ensuite dans IViewer, tu ajoutes des méthodes
boolean supportSousElement(SousElement2 sousElement2)
boolean supportSousElement(SousElement2 sousElement2)

Comme ça dans la méthode isSupportedByViewer, tu appelles viewer.supportSousElement(this) et ça va appeler la bonne méthode du viewer qui retournera true ou false suivant si le viewer doit afficher le sousElement.

Avec cette méthode, pour ajouter un viewer, tu n'as pas besoin de toucher aux autres classes, tu as juste à définir quels sous-elements il supporte.

Oui, le pattern Visitor est une solution. Le problème ici, c'est que les SousElement sont des classe concrètes. Dès qu'on va vouloir rajouter une autre classe implémentant ISousElement, il faudrait aussi changer le IViewer.

A priori, vu que ton système est extensible par plugin, tu ne peux pas utiliser le pattern visiteur. L'idée de tout mettre dans une seule liste n'aurait d'intérêt que si le même Viewer pouvait afficher n'importe quel SousElement, or ce n'est pas le cas.
Une autre suggestion :

Code:

---

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

Map<Class<? extends ISousElement>, List<ISousElement>> mapContainers = new HashMap<Class<? extends ISousElement>, List<ISousElement>>();   public List<ISousElement> getListe(Class<? extends ISousElement> clazz) { List<ISousElement> liste = mapContainers.get(clazz); if (liste == null) { liste = new ArrayList<ISousElement>(); mapContainers.put(clazz, liste); } return liste; }   public void add(ISousElement se) { List<ISousElement> liste = getListe(se.getClass()); liste.add(se); }

---

Oui c'est vrai.

Mais afin de ne pas devoir changer toutes les classes qui implémentent IViewer, il suffirait de faire un AbstractViewer qui l'implémente, et par défaut refuse ou accepte tous les sous-éléments.
Ensuite les viewers concrets étendent AbstractViewer et surchargent uniquement les méthodes des sous-éléments qui les intéressent.

Du coup, quand on ajoute un SousElement, on a uniquement l'interface et la classe abstraite à modifier.

Citation:

---

Envoyé par CheryBen

Du coup, quand on ajoute un SousElement, on a uniquement l'interface et la classe abstraite à modifier.

---

C'est difficilement compatible avec une extension des SousElements par plugin.

Effectivement le pattern visiteur serait une bonne idée dans le cadre d'un système non extensible. J'en avais entendu parler sans en comprendre le réel intérêt car jamais confronté au problème, c'est tout de suite plus clair quand on se trouve face à la situation !

Par contre, l'idée d'une Map<Class<? extends ISousElement>, List<ISousElement>> est vraiment très bonne !
C'est dynamique, extensible et tout.
Bref, j'adopte cette solution !

Merci à tous !