Discussion :

[r0d]

Bonjour,

c'est un problème de conception, mais la solution va certainement être très spécifique au c++, c'est pourquoi je poste ici.

Je travaille sur une application qui, basiquement, affiche des images à l'écran. Ces images ont diverses propriétés. Par exemple elles peuvent bouger, et/ou être cliquées, et/ou être sélectionnées, etc.

J'ai donc décidé d'opter pour une programmation par contrat: j'implémente des interfaces (Movable, Clickable, Selectionnable, etc.) et mes images (Sprites) héritent des ces interfaces en fonctions des besoins.

Jusqu'ici tout va bien, et ça marche plutôt pas mal (je veux dire d'un point de vue de l'architecture: tout s'emboite bien, et les modifications/ajouts de fonctionnalités se passent bien).

Mais maintenant, je voudrais que mes images puissent changer de comportement. Par exemple, immobiliser une image qui était "movable". Il faudrait donc que je lui enlève l'interface Movable. Or ce n'est évidemment pas possible.

Donc en fait, le problème c'est que j'ai des objets qui sont suscpetibles de changer d'état finalement. Ce qui pourrait m'orienter vers l'utilisation du dp state. Mais l'utilisation de ces interfaces est vraiment hyper pratique, propre, et assez élegant je trouve. Et puis là je vous en donne 3, mais en vrai il y en a plus. Je ne voudrais donc pas laisser tomber ces interfaces. Mais alors comment faire pour que mes objets puissent changer d'état?

J'aimerais également éviter de reconstruire mes objets lorsqu'ils changent d'état, car j'utilise un gestionnaire de mémoire pour les images très optimisé mais très peu pratique.
J'ai l'intuition que je vais avoir besoin de templates...

J'espère avoir été clair. Si ça ne l'est pas, dites-le moi je posterai un diagramme, c'est toujours plus parlant.

[Mat007]

Salut,

Là comme ça, ça me fait plutôt penser au design pattern décorateur.

MAT.

[Flob90]

Si je comprends bien tu as quelque chose comme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class InterfaceA
{
  virtual void fooA() =0;
  protected:
    virtual InterfaceA(){}
}
//Idem pour B, C, D, ... plein
class SpriteA : public InterfaceA
{Data d; public: void fooA(){/*Code utilisant d*/} };
class SpriteAB : public InterfaceA, public Interface B
{ /*code*/ };
/*idem plein d'autre*/
//Avec une classe de base commune peut-etre ?

Et tu voudrais faire un truc du genre :

Code :

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

1
2
3
 
SpriteAB s;
s.remove<InterfaceA>();

Si c'est ca me semble difficile "sans rien créer" d'autre, car l'interface est lié au type statique, et tu ne peux pas le changer sans rien créer.

Tu pourrais passer par un système qui isole l'implémentation de ta classe de son interface (comme PImpl), ca permettrait au système qui gère la mémoire de ne s'occuper que de ces derniers, et dans la couche supérieur tu pourrais switcher entre les interfaces en créant de nouveau objet.

Quelque chose comme ca (j'ai fait ajouter une interface). pour en retirer une, avec ce code il faut déterminer la listes des types voulue (enlever l'interface qu'il faut, boost doit proposer ca), et après c'est pareil que pour add.

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
42
43
44
45
46
 
struct SpriteImpl
{ /*data*/ };
 
class BaseSprite
{ 
  BaseSprite(const BaseSprite&) =delete;
  template<class,class...> friend class ManageInterface;
  protected:
    SpriteImpl* p;
    void take(BaseSprite& s) { std::swap(p,s.p); delete s.p; s.p = NULL; }
  public:
    BaseSprite() : p(new SpriteImpl()) {}
    virtual ~BaseSprite(){ delete p; }
};
 
template<class...> class Sprite : public BaseSprite {};
 
template<class Interface, class... Arg>
class ManageInterface
{ protected: ~ManageInterface(){}
  public:
    template<class T>
    std::unique_ptr<Sprite<T,Interface,Arg...> > add()
    { Sprite<T,Interface,Arg...>* s = new Sprite<T,Interface,Arg...>(); 
      s->take(*(reinterpret_cast<BaseSprite*>(this)));
      return std::unique_ptr<Sprite<T,Interface,Arg...> >(s); }
};
 
class InterfaceA;
template<class... Arg>
class Sprite<InterfaceA,Arg...> :
  public Sprite<Arg...>, public ManageInterface<InterfaceA,Arg...>
{ public: virtual void fooA(){/*impl*/} };
 
class InterfaceB;
template<class... Arg>
class Sprite<InterfaceB,Arg...> :
  public Sprite<Arg...>, public ManageInterface<InterfaceB,Arg...>
{ public: virtual void fooB(){/*impl*/} };
 
//Exemple d'utilisation
Sprite<InterfaceA> s;
s.fooA();
auto s2 = s.add<InterfaceB>();
s2->fooB();

Si c'est pas du tout l'objectif que tu as, alors je n'ai pas compris la question.

<Edit> Et on peut faire une macro sur le code pour éviter la répétition quand on définie de nouvelles interfaces :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
#define Interface(E) \
class Interface##E; \
template<class... Arg> \
class Sprite<Interface##E,Arg...> : \
  public Sprite<Arg...>, public ManageInterface<Interface##E,Arg...> \
 
//Génère le code concernant InterfaceA dans le début du code
Interface(A)
{ public: virtual void fooA(){/*impl*/} };

</Edit>

[screetch]

hmmm dans ce cas je n'aime pas trop l'héritage. De la composition serait peut être plus efficace.

Code :

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

1
2
3
4
5
6
class Region
{
  Movable* onMove;
  Clickable* onClick;
  Selectionnable* onSelected;
};

ainsi il suffit de remplacer le onMove pour changer le comportement de déplacement, sans changer le comportement de clickable ou selectionnable.

[Goten]

hmmm dans ce cas je n'aime pas trop l'héritage. De la composition serait peut être plus efficace.

Code :

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

1
2
3
4
5
6
class Region
{
  Movable* onMove;
  Clickable* onClick;
  Selectionnable* onSelected;
};

ainsi il suffit de remplacer le onMove pour changer le comportement de déplacement, sans changer le comportement de clickable ou selectionnable.

+1 pour la composition. (mais pourquoi des pointeurs?)

[screetch]

bah pour le polymorphisme? j'ai dit une betise?

[Invité]

Salut,

Mais maintenant, je voudrais que mes images puissent changer de comportement. Par exemple, immobiliser une image qui était "movable". Il faudrait donc que je lui enlève l'interface Movable. Or ce n'est évidemment pas possible.

La solution va dépendre de ce que tu entends par "changer".

Si ce que tu veux, c'est "juste" que certains les comportements puissent être inhibés, alors le plus simple est d'ajouter une propriété "Enabled" à tes interfaces. Celle ci sera vérifiée à chaque fois qu'on utilise l'interface. En gros, un objet cliquable est toujours cliquable (potentiellement) mais sa "cliquabilité" peut être désactivée via la propriété Enabled...

Ca a le mérite d'être très simple, quoiqu'un peu intrusif si tu l'implémentes dans du code existant (encore que... si tu pars du principe que tes interfaces sont actives par défaut...).

Si tu veux que la même interface puisse changer de comportement, alors tu es davantage dans l'approche "gestionnaire d'évènements" que suggérait Screetch. En gros, tes interfaces communiquent avec ton objet au travers de foncteurs, que tu peux "débrancher", un "cliquable désactivé", c'est alors un objet dont le "foncteur de clic" est débranché. Cette seconde approche est plus puissante (elle va te permettre de modifier les comportements de tes interfaces à l'éxécution), mais également plus lourde à mettre en oeuvre.

Ce genre de situation est très courant dans les librairies d'interface. La difficulté,c'est que tes comportements (ie les fonctions membres de ton interface) vont devoir faire référence à l'instance qui les appelle (et donc connaitre son type, ses membres...). C'est un peu plus compliqué qu'un pointeur de fonction.

Traditionnellement, c'était géré en utilisant des hiérarchies dérivant d'objets communs (c'est comme cela que font la VCL de Borland, et Qt, en partie). Le 'super objet' avait pour seule fonction de permettre cette "communication ascendante' entre le gestionnaire d'évènement et son appelant.

Aujourd'hui, on recommanderait de faire sans "super Objet". C'est faisable, mais pas aussi simple que ca en a l'air. Si tu te lances là dedans, regarde le chapitre "smart pointers" de Modern C++ Design (Alexandrescu)... Ca permet de bien comprendre la problématique (même si après tu utilises une solution préfabriquée).

Francois

[r0d]

Bonjour,

pardon de n'avoir pas répondu avant, j'étais en déplacement ces jours-ci.
Je vais regarder tout ça puis je vous tiens au courant.
Merci pour vos réponses

[r0d]

Ok alors après réflexion, je pense que le plus simple et le moins compliqué ce sera un décorateur. Ce qui, finalement, reviens à la proposition de screetch. Je vais donc partir là-dessus, on verra si je rencontre des difficultés insurmontables

Au passage, dans cette situation moi je n'ai aucun scrupule à utiliser des pointeurs nus. En effet, ces pointeurs ne seront pas exportés en dehors de la classe, et je pense même pouvoir les gérer dans une classe "super object" commune à tous les types de sprite.

Enfin, peux-être dis-je des bêtises et les problèmes apparaîtrons lors de l'implémentation. On verra