[Design Pattern]Export de données

Bonjour,

je ne sais pas si l'un de vous a déja été conforonté au problème que j'ai mais je cherche un desin patern qui pourrait correspondre a mon probleme.
Le problème est simple:
- j'ai plusieurs sortes de données : données A, données B , etc ...
- j'ai plusieurs sortes de format : format A, format B , etc ...

le but c'est chaque donnée puisse etre formattée selon le format A ou B c'est à dire que les résultats possibles sont les suivantes dans mon exemple :

1: données A formattées avec le formattage A
2: données A formattées avec le formattage B
3: données B formattées avec le formattage A
4: données B formattées avec le formattage B

voilà , je ne vois pas trop quels DP je pourrais utiliser alors si vous avec une idée n'hésitez pas à m'en faire part !
en vous remerciant d'avance ! :)

bonjour

vu de loin, le pattern visitor pourrait convenir :
un visiteur abstrait (méthodes abstraites visiteA(donnéeA) et visiteB(donnéeB)),
un visiteur concret qui exporte avec le formattage A,
un autre visiteur concret qui exporte avec le formattage B.

cf. http://en.wikipedia.org/wiki/Visitor_pattern

Tu dois absoluement utiliser un design pattern ou pas ?

merci de vos réponses :)

le DP visitor je connaissais pas trop mais apparement apres une longue recherche sur le oueb, le DP Stratégie semble convenir à mon problème à savoir l'export de données vers différent formats de fichiers.Je suis en train de me pencher sur ca car il m'a lair plus simple que Visitor aussi :)

si je dois absolument utiliser un design pattern ? je préfère,car c'est un programme fini mais tres rigide et j'ai du mal a rajouter des fonctionalités sans provoquer des bugs partout :? d'ou je pense que c'est mieux , sinon t'allais peut etre proposer autre chose ?

Mois je dirais que c'est juste une histoire d'implémentation. Si une donnée A peut être exportée au formats X et Y, cela signifie que la donnée A possède une implémentation dédiée pour chacun des formats d'export. C'est à cela que servent les interfaces dans les langages à objet.

Pour notre exemple cela donne :

Code:

---

1 2 3 4 5 6

public class DonneA implements FormatX, FormatY { . . . }

---

Le pattern strategie utilise effectivement ce principe d'interface, c'est à dire d'indépendance entre les fonctionnalités offertes et l'implémentation choisie pour ces fonctionnalités.

La solution d'Hephaistos007 est la plus "objet" : un objet sait rendre tous les services qu'on peut lui demander. Seul inconvénient : les classes ont tendance à grossir (reste à savoir jusqu'à quel point c'est acceptable), et finissent par mélanger des concepts techniques très différents.

C'est pour ça qu'on utilise parfois des déléguations de comportements (d'où l'utilisation des patterns strategie et visiteur).

Le pattern strategie oblige a identifier une interface commune entre les 2 formattages, et surtout un protocol d'utilisation identique. La responsabilité du formattage (en A et en B) repose sur l'objet (qui sait dans quel ordre enchaîneer les appels de méthodes de la stratégie) et sur la stratégie (qui formatte les données qu'elle reçoit).

Le pattern visiteur permet de centraliser la responsabilité d'un formattage sur les seuls visiteurs (et pas sur l'objet concerné). Ce pattern est donc plus souple que la stratégie.

selon les patterns GRASP :
- l'objet est "expert en information" (ok pour les 3 solutions)
- les comportements annexes (si le formattage en est un) sont mis dans une "fabrication pure" (les 2 design patterns)

La contre-partie du pattern visiteur est de souvent devoir briser l'encapsulation des objets concernés, ce qui n'est pas propre... donc attention à l'usage que l'on fait des objets (A ou B) par la suite.