Discussion :

[guams]

Bonjour,

Je travaille actuellement sur une application java standalone qui utilise des fichiers (assez gros) en entrées pour produire des documents variés en sortie.
Cette application doit être utilisée comme API d'un atelier pour générer ses documents, mais sans avoir connaissance de cet atelier.
Le coeur de l'atelier est un basique pattern composite, avec visiteurs associés.

Pour pouvoir parser les objets de mon atelier je comptais donc passer par un jar d'interface, qui serait un "composite d'interface" à l'image de la structure présente dans l'atelier.
Le problème est que ça m'oblige à rajouter dans la centaine de classes composant la structure composite de l'atelier l'information comme quoi elles implémentent cette nouvelle interface.
Ça m'oblige aussi à redéfinir un nouveau visiteur mais qui manipulerait les interfaces (je ne sais d’ailleurs pas si le double dispatch fonctionne sur les interfaces...).

Je ne suis pas très à l'aise avec cette approche, j'ai l'impression que ce n'est pas la bonne manière de procéder, peut être parce que ça m'oblige à rajouter des interfaces "artificielles" du point de vue de l'atelier.

Qu'en pensez vous?
Et voyez vous une autre manière de faire?

[Cincinnatus]

Un peu tard, mais au cas où ça servirait...

Il me semble que le pattern serait plutôt celui de façade. Sous réserve d'avoir compris le contexte...

[PanicKernel]

L'approche composite/visiteur me paraissait pas mal.

Peut-être que la structure des classes qui implémentent le composite n'est pas correcte ? Il manque peut-être des abstractions intermédiaires qui simplifieraient du coup les visiteurs ?

Difficile d'en dire plus avec ce que je sais.