Discussion :

[olivier1978]

Bonjour,

[Ce topic est relie a celui-ci http://www.developpez.net/forums/sho...d.php?t=403682 pour ceux qui ont suivi la discussion]

Alors voila. J'ai un objet auquel j'applique des transformations, que, dans certains cas, je n'accepte pas. Cependant, je suis obligé de faire effectivement cette transformation pour savoir ou pas si ja la valide.

Pour etre plus precis, j'applique des transformations geometriques (translations, rotations, dilatations, ...) a des formes geometriques. Devant de temps à autre revenir en arrière, c'est à dire retrouver l'état initial de ma forme, je me demandais si le pattern Memento était fait pour moi.

En fait, je ne comprends pas bien en quoi il permet de ne pas exposer l'interface. Un petit coup de main ?

D'avance merci

[bolhrak]

Le pattern permet de ne pas exposer l'interface des classes que tu manipules dans la mesure où ce sont les objets de ces classes qui restaurent leur état, tu n'as pas à fournir de méthodes supplémentaires pour gérer ça de l'extérieur et ainsi exposer des détails d'implémentation.

Maintenant savoir si c'est le plus adapté, ça dépend de la manière dont sont implémentés tes objets et de ce que font réellement tes transformations. Tu as deux manières de gérer les annulations :

- le memento, qui contient toutes les données correspondant à l'état que tu veux restaurer.
- appliquer une transformation inverse pour revenir à l'état initial, cette méthode étant pas mal dans le cas où tu as beaucoup de variables de classes dépendantes à mettre à jour, où si ta transformation implique des appels à des méthodes d'autres objets.

Perso je suis pas fan du Memento, ça oblige à écrire pas mal de code supplémentaire pour stocker des variables d'état, si tu veux garder un historique relativement important de tes commandes ça commence à consommer pas mal de mémoire, et dans le comportement polymorphique est pas évident à mettre en place dans le cas d'une hiérarchie de classes.

Excepté dans le cas où les changements d'état sont très gourmandes en temps de calcul, je préfère stocker une paire de foncteur (fonction appliquée pour le redo, fonction inverse pour l'undo) avec les arguments à passer.

[koala01]

Salut,

Ceci dit, dans le cadre que tu explique, une modification "complexe" (grossissement, déplacement et rotation) n'étant qu'une suite de modification "simple", il *devrait* effectivement te permettre de mettre au point quelque chose se rapprochant des "transaction" en SQL et de leur sytème de "rollback", avec leur sigle ACID(Atomique, Cohérente, Isolée et Durable), sans avoir besoin de retenir ni les états réels intermédiaires, ni même les états "finaux"

Si cela entre dans l'idée générale, rien ne t'empêche d'assurer la "durabilité" en effaçant au fur et à mesure les modifications acceptées pour économiser ta mémoire

Le tout étant que chaque modification "simple" dois pouvoir être inversée facilement

[Kujara]

A noter que si tu travaille sur des objets 3D, comme j'en ai l'impression, tu peux te contenter de "sauvegarder" des matrices 4D, soit en tant qu"etat total de ton objet a un instant T avant la transformation, ce qui te permet de revenir a un etat 3 transformations avant en une fois, soit en tant que matrice 4x4 de transformation de ton objet, auquel cas pour revenir 3 fois en arriere, tu devras faire 3 fois les calculs.

[valefor]

Je ne sais pas si c'est valable. Mais on pourrait aussi faire une copie de l'objet, y appliquer la transformation, le jeter si c'est pas bon, jeter l'ancien si c'est bon. Mais j'imagine que ce n'est pas optimal comme soluce.