Discussion :

[bolhrak]

Bonjour,

Je suis en train de réaliser une librairie d'UndoManager (du moins je commence :p), le principe est de gérer deux stacks, une pour les undos, l'autre pour les redos. Jusqu'à présent j'avais pensé à quelque chose du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
 
class UndoManager {
 
    std::stack<UndoRedo*> m_undo_stack;
    std::stack<UndoRedo*> m_redo_stack;
 
};
 
class UndoRedo {
 
    public:
 
        virtual void undo() =0;
        virtual void redo() =0;
 
};
 
template <class UndoFunctor, class RedoFunctor>
class UndoItem : public UndoRedo {
 
    private:
        UndoFunctor m_undo;
        RedoFunctor m_redo;
 
    public:
 
        virtual void undo(); //appel m_undo()
        virtual void redo(); //appel m_redo()
 
};

Bref somme toute quelque chose de relativement simple. En farfouillant un peu sur le net, je suis tombé sur un article décrivant une implémentation d'undoManager de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
 
template <class F>
class UndoRedo {
 
    private:
        F f;
 
    public:
 
        void undo() { f.undo(); }
        void redo() { f.redo();}
 
};
 
template <class F>
class UndoManager {
 
    std::stack<UndoRedo<F> > m_undo_stack;
    std::stack<UndoRedo<F> > m_redo_stack;
 
};
 
class UndoAction {
 
    public:
 
       virtual void undo() =0;
       virtual void redo() =0;
 
};
 
template <class UndoFunctor, class RedoFunctor>
class Concrete UndoAction : public UndoAction {
 
//identique à UndoItem du design précédent
 
};
 
//Instanciation de l'undomanager :
UndoManager<UndoAction> manager;

Je ne comprends pas l'intérêt de rajouter une indirection supplémentaire. Dans le premier design, on a une interface pour les undo, et une class d'implémentation paramétrée pas les deux types de functors utilisés.

Dans le second cas, on paramètre une classe d'UndoAction par une interface UndoRedo, implémentée par la classe concrète du design précédent.

Y'a-t-il un réel intérêt à faire cela ?

[Matthieu Brucher]

Ta version est plus cohérente avec ce qu'est un undo/redo, à savoir un pattern command. Je te conseille de rester sur ton idée

[Patriarch24]

Il vaut toujours mieux aller au plus simple. Si ton design te conviens pour l'utilisation que tu en auras, garde le. En réalité, les deux versions sont équivalentes. Dans un cas, il s'agit de polymorphisme d'inclusion (héritage de UndoRedo), dans l'autre cas, de généricité (paramétrage de UndoRedo par une classe disposant de l'interface adéquate).

[bolhrak]

La deuxième solution utilise également le polymorphisme, et je ne vois pas l'intérêt d'une class template UndoRedo, puisque le paramètre est ici une interface, que l'on pourrait donc utiliser de manière directe. Disons que je ne vois pas en quoi le premier design est moins générique que le second, dans tous les cas mon interface doit disposer de méthodes Undo et Redo.

Merci pour vos réponses :p

[Matthieu Brucher]

Dans le second cas, les pbjets que tu vas stocker n'héritent pas forcément de ta classe abstraite, ils peuvent simplement fournir une interface avec redo et undo.

[bolhrak]

Ok, donc intéressant si on souhaite implémenter les undo actions avec d'autres moyens que des foncteurs.

Merci beaucoup :p