[Resolu][C++] Question Architecture avec interface multiple

Question Architecture avec interface multiple [Resolu][C++] - C++ - Programmation

Marsh Posté le 22-12-2009 à 15:45:35    

[C++] Question Architecture avec interface multiple
 
Bonjour,
 
j'ai une classe Objet qui possède comme donnée des coordonnées

Code :
  1. class Object
  2. {
  3.   int x;
  4.   int y;
  5. };


Suivant les endroits ou je me trouve dans l'application, je voudrais qu'il soit vu comme un Displayable(pour son affichage à l'écran) ou comme un TargetObject (pour d'autres opérations) . Displayable et TargetObject sont vu un peu comme des interfaces

Code :
  1. class Displayable
  2. {
  3.   int x;
  4.   int y;
  5.   void display();
  6. };
  7. class TargetObject
  8. {
  9.   int x;
  10.   int y;
  11.   void compute();
  12. }


 
Le but étant de pouvoir gérer une liste d'objet, tantôt comme une liste de Displayable, tantôt comme une liste de TargetObject
 
Je pensais faire hériter object des 2 précédentes classes

Code :
  1. class Object : public Displayable, public TargetObject{...}


 
Mais dans ce cas je me retrouve avec 3 variable x (et y) différentes, et comme elles doivent tout le temps avoir la même valeur, cela devient difficile à gérer pour les modifier en même temps et il y a redondance d'information, d'autant qu'il y a évidement d'autres variables.
 
De plus mes classes doivent pouvoir être héritées
 
Je peux aussi faire une agrégation du genre  

Code :
  1. class Object {
  2.   int x;
  3.   int y;
  4.   Displayable _display;
  5.   TargetObject _target;


L'avantage de la dernière méthode est que je peux utiliser des monteur pour créer mes classe héritées de object, à partir des classe héritées de Displayable et TargetObject mais j'ai le même problème de MAJ des données et de redondance
 
Je ne peux pas non plus supprimmer x et y de mes interface, car sinon je n'aurais plus accès à leur valeurs...
 
Est ce quelqu'un à une idée pour partager les données x et y pour que la modification via une "interface" (Displayable ouTargetObject) soit générale à tout l'objet de base ?
 
Merci d'avance


Message édité par toonj le 23-12-2009 à 10:32:02
Reply

Marsh Posté le 22-12-2009 à 15:45:35   

Reply

Marsh Posté le 22-12-2009 à 16:07:38    

Du polymorphisme, ça n'irait pas ?


Message édité par kao98 le 22-12-2009 à 16:07:48

---------------
Kao ..98 - Uplay (R6S) : kao98.7.62x39 - Origin (BF4, BF1) : kntkao98
Reply

Marsh Posté le 22-12-2009 à 17:00:06    

uh oui , c'ets la base basique :
 

Code :
  1. class displayable
  2. {
  3.   public:
  4.    virtual void display() = 0;
  5. };
  6. class computable
  7. {
  8.   public:
  9.   virtual void compute() = 0;
  10. };
  11. class object : public displayable, public computable
  12. {
  13.    public:
  14.    virtual ~object();
  15.   // surcharge des interfaces
  16.   virtual void display() { /* du code*/ }
  17.   virtual void compute() { /* du code*/ }
  18.   private:
  19.   int x,y;
  20. };

Reply

Marsh Posté le 22-12-2009 à 17:08:52    

effectivement, sauf que je voudrais pouvoir maintenir mon code display() et compute() en dehors de ma classe Object : si je veux un jour changer les propriétés d'affichage (passage 2d vers 3D par exemple), je ne veux pas avoir à toucher à ma classe Object et ses dérivés (j'ai oublié de préciser cette contrainte)

Reply

Marsh Posté le 22-12-2009 à 23:13:22    

toonj a écrit :

effectivement, sauf que je voudrais pouvoir maintenir mon code display() et compute() en dehors de ma classe Object : si je veux un jour changer les propriétés d'affichage (passage 2d vers 3D par exemple), je ne veux pas avoir à toucher à ma classe Object et ses dérivés (j'ai oublié de préciser cette contrainte)


 
 :)  

Message cité 1 fois
Message édité par __tomjost le 23-12-2009 à 00:03:41
Reply

Marsh Posté le 23-12-2009 à 00:09:38    

__tomjost a écrit :


 
 :)  passe quelque parameter/info  , ou meme
une l'address de function qui va faire le travail
a Display(); , et c'est tout :D  


Reply

Marsh Posté le 23-12-2009 à 00:10:57    

toonj a écrit :

effectivement, sauf que je voudrais pouvoir maintenir mon code display() et compute() en dehors de ma classe Object : si je veux un jour changer les propriétés d'affichage (passage 2d vers 3D par exemple), je ne veux pas avoir à toucher à ma classe Object et ses dérivés (j'ai oublié de préciser cette contrainte)


 
Alors tu fais des classes d'affichage et de traitement qui prennent en paramètre un de tes objets.

Reply

Marsh Posté le 23-12-2009 à 08:55:01    

L'idée d'une classe d'affichage me plait bien
Ca donne (si j'ai bien tout compris !) quelque chose comme ça :

Code :
  1. class Object
  2.    {
  3.      int x;
  4.      int y;
  5.      Displayable _currentDisplay;
  6.      Computable _currentCompute;
  7.      Object(Displayable display, Computable compute) {_currentDisplay = display; _ currentCompute = compute;}
  8.      void display() {_currentDisplay.display(this);}
  9.      void compute() {_currentCompute.compute(this);}
  10.    };
  11. class Display
  12. {
  13.   public virtual void display(Object) = 0;
  14. };
  15. class Display2D : public Display
  16. {
  17.    void display(Object){//Affichage 2D}
  18. };
  19. class Display3D : public Display
  20. {
  21.    void display(Object){//Affichage 3D}
  22. };
  23. class Computable
  24. {
  25.    virtual void compute(Object){....};
  26. };


 
d'autres idées, ou des commentaires ?


Message édité par toonj le 23-12-2009 à 08:56:02
Reply

Marsh Posté le 23-12-2009 à 08:57:53    

oui c'est pas mal ça.

Reply

Marsh Posté le 23-12-2009 à 10:19:18    

Tu peux également utiliser des politiques : http://alp.developpez.com/tutoriels/type-erasure/#LIV

Reply

Marsh Posté le 23-12-2009 à 10:19:18   

Reply

Marsh Posté le 23-12-2009 à 10:31:15    

lien très intéressant, merci
 
Je considère le sujet comme résolu.

Reply

Marsh Posté le 23-12-2009 à 11:30:57    

toonj a écrit :

effectivement, sauf que je voudrais pouvoir maintenir mon code display() et compute() en dehors de ma classe Object : si je veux un jour changer les propriétés d'affichage (passage 2d vers 3D par exemple), je ne veux pas avoir à toucher à ma classe Object et ses dérivés (j'ai oublié de préciser cette contrainte)


Tu vas faire comment pour passer en 3d sans modifier ta classe objet alors que c'est la que tu mets tes coordonées (x,y)? a moins que la composante z sera constante ?

Reply

Marsh Posté le 23-12-2009 à 12:51:00    

Personnellement je ne mettrais même pas un membre affichage ou de traitement.
 
La logique c'est d'avoir une classe modèle/document qui maintiens ta géométrie/éléments.
Ensuite tu as des classes qui manipulent, affichent.....
 
Dans une image tu stockes pas par pixel les dépendances vers chaque action que tu peux faire par pixel.
 
Enfin a voir ce que tu veux faire, mais là ça me parait over-engineered pour rien.

Message cité 1 fois
Message édité par bjone le 23-12-2009 à 12:54:09
Reply

Marsh Posté le 23-12-2009 à 22:21:14    

bjone a écrit :

Personnellement je ne mettrais même pas un membre affichage ou de traitement.
 
La logique c'est d'avoir une classe modèle/document qui maintiens ta géométrie/éléments.
Ensuite tu as des classes qui manipulent, affichent.....
 
Dans une image tu stockes pas par pixel les dépendances vers chaque action que tu peux faire par pixel.
 
Enfin a voir ce que tu veux faire, mais là ça me parait over-engineered pour rien.


 
 :sol:  tu vas trop loin avec cette class , ...  :lol:  
mais je crois que j'ai compris la logique , faut une seul Display()
, a la fin cet objet va etre afficher en 2D sur l'ecran , les autre dimensions
(1,3,4 ...) vont devenir 2D , alors les methods devient Compute3D , Compute4D
(ou Render3D Render4D mieux )
puis call Display() , [.... mais c'est quoi cette class  :heink: ]

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed