Discussion :

[N_I_C_S]

Salut,

Dans le cadre d'un projet J2EE, j'ai pensé à ce qui pourrait être un DP intéressant, quoiqu'assez spécialisé. Je l'ai nommé "Ordonner" et sa vocation serait de modéliser les processus de tri de manière trés modulaire. Voici à quoi ressemblerait le diagramme de classes :




Les avantages sont :

1. Le processus de tri est totalement séparé des objets à trier.
2. Le critère de comparaison des objets est indépendant de l'algorithme de tri. Il peut donc être modifié, remplacé, manipulé dynamiquement.
3. L'algorithme de tri étant lui aussi indépendant, il peut être choisi dynamiquement selon une stratégie d'optimisation des performances.

Par exemple (c'est un exemple très bête...), on voudrait ordonner certaines villes de France selon la proximité de leur température journalière avec la moyenne nationale.

La Target serait la liste de ces villes (à priori pas du tout faîtes pour être ordonnées ainsi), l'Ordonner contiendrait plusieurs algos de tri choisi en fonction de la taille de la liste (nationale, régionale, ...), et le Comparer irait chercher la moyenne du jour pour trouver, entre deux villes, laquelle est la plus proche.

J'aimerais avoir :

1 - Votre avis sur la modélisation du diagramme.

2 - Votre avis sur la pertinence du concept.

3 - Savoir s'il existe des organisations d'homologation et de diffusion des design patterns. Je pourrais tenter ma chance...

Merci !

[pcaboche]

Si j'ai bien compris, ton "Ordonner" est en fait un Decorateur sur une liste avec une Stratégie pour savoir sur quels critères trier la liste, c'est ça? Dans ce cas, c'est l'association des patterns Decorateur et Strategy. Intéressant, mais de là à en faire un nouveau pattern...

Par ailleurs, ce design reprend un concept connu depuis fort longtemps en Java (et pas uniquement) : le Comparator (ici, renommé "Comparer"). Bref, c'est pas très nouveau.

1 - Votre avis sur la modélisation du diagramme.

C'est correct, à part la flèche entre Invoquer et Target dont on a du mal à comprendre l'intérêt (dans le cas où "ConcreteOrdonner" est un décorateur, on n'accède pas directement à la liste "Target").

2 - Votre avis sur la pertinence du concept.

Exprimé en début de message.

3 - Savoir s'il existe des organisations d'homologation et de diffusion des design patterns. Je pourrais tenter ma chance...
Merci !

Pas à ma conaissance.


A part ça, c'est un excellent premier message, avec une idée intéressante. J'espère qu'on te reverra bientôt sur les forums de DVP pour nous exposer tes idées.

@+

[Matthieu Brucher]

3) Regarde ici : http://hillside.net/patterns/

[N_I_C_S]

Ok, merci pour vos éclairages.
En fait, je ne connais que peu de design patterns, je me doutais un peu que d'autres structures existaient déjà...

C'est correct, à part la flèche entre Invoquer et Target dont on a du mal à comprendre l'intérêt (dans le cas où "ConcreteOrdonner" est un décorateur, on n'accède pas directement à la liste "Target").

Effectivement, maintenant que tu le dis, cette flèche est assez maladroite. En fait, je voulais représenter le fait que l'Invoker avait pour rôle d'envoyer la Target à l'Ordonner.Ca ne mérite peut-être pas une relation...

Merci à tous et a++

[ego]

Juste un point, tout ce que tu présente est du standard dans l'API Java. Je ne vois pas pourquoi le ré-inventer !?

[N_I_C_S]

Salut eqo,

je suppose que tu parles de l'interface Comparable et de la méthode Collections.sort(). Le problème est que ce système a 2 limitations qui ne me convenaient pas : d'une part il oblige à implémenter l'interface d'avance à l'intérieur de chaque classe susceptible un peu, beaucoup, peut-être, peut-être pas d'être triée un jour, et d'autre part on n'a aucun contrôle sur l'algo de tri (je crois que l'algo de java est le tri à bulle, pas forcément le plus performant en toutes circonstances).

De plus, pour des raisons de performance, je voulais éviter les liaisons dynamiques. En fait, mon projet est une plate-forme 3D 100% software, ma recherche est donc portée prioritairement sur la rapidité. Le p'tit dessin du premier message est une généralisation, dans mon projet je n'ai pas utilisé d'interface ou de classe abstraite.

Voilà, mon but était de rajouter un système de tri rapide et modulaire sans toucher à des objets déjà existants, ce que la lib java ne propose pas vraiment.

[pcaboche]

je suppose que tu parles de l'interface Comparable et de la méthode Collections.sort().

Il ne voulait pas parler de l'interface Comparable mais Comparator.

(je crois que l'algo de java est le tri à bulle, pas forcément le plus performant en toutes circonstances).

Faux !

C'est un tri fusion (merge sort, qui a la propriété d'être stable, contrairement au quick sort, par exemple) sauf pour des Collections de 7 éléments ou moins où effectivement il s'agit d'un tri à bulles (des tests ont montré que pour des Collections contenant au plus 7 éléments, le tri à bulle était plus rapide car ne nécessitant pas d'appels récursifs).

[ego]

Pour l'histoire de "mes objets doivent hériter de l'iterface Comparable", je ne suis pas d'accord.
Plusieurs points sur tout cela :
- Il y a l'interface Comparator qui permet de ne pas demander aux objets d'implémenter une interface particulière
- L'interface Comparable est à implémenter s'il y a une relation d'ordre "standard", "intrinsèque" à tes objets
- Si la relation d'ordre est contextuelle, tu peux utiliser Comparator ou créer des proxies sur tes objets. Ces proxies implémentent eux, l'interface Comparable. Dans un contexte donné, tu va donc créer autant de proxy que d'objet à trier et c'est ton proxy que tu donnes à ton algo de tri.

Mais bon, si tu as d'autres bonnes raison pour tout refaire.

Juste un dernier point, as-tu testé l'API Java standard avant de dire qu'elle n'était pas assez performante pour tes besoins ?

[N_I_C_S]

Salut, I'm back !

Je vous remercie pour vos fructueux commentaires, le coup du proxy, j'y avais pas pensé !

Ca m'a fait prendre conscience d'une mauvaise modélisation de l'idée, trop proche de java. Afin d'éviter les confusions, je repropose ceci :


Y a pas grand changement mais ça permet peut-être de généraliser le "pattern", celui-ci devant être théoriquement indépendant du langage et de ses facilités.

Quant au fait que je n'utilise pas les classes java dans mon appli, c'est précisément pour éviter les héritages avec ces classes. En fait, l'appli utilise cette structure :


Ce système de tri se situe à bas niveau (si tant est qu'on puisse utiliser ce terme en java !) et le nombre d'objets à trier est pour l'intant petit. J'ai donc choisi de me passer des liaisons dynamiques et de gérer l'algo de tri plutot que l'inverse. Maintenant, il serait intéressant d'étudier le ratio de temps (performance algo de l'API / [nombre*performance]liaisons), certainement linéaire en moyenne par rapport au nombre d'objets. Sur un petit nombre, je pense que les liaisons handicappent l'algo (fusion, oops ).