Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1688 connectés 

  FORUM HardWare.fr
  Programmation
  C++

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

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

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

n°1952442
toonj
Posté le 22-12-2009 à 15:45:35  profilanswer
 

[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. };
  8. class TargetObject
  9. {
  10.   int x;
  11.   int y;
  12.   void compute();
  13. }


 
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
mood
Publicité
Posté le 22-12-2009 à 15:45:35  profilanswer
 

n°1952453
kao98
...
Posté le 22-12-2009 à 16:07:38  profilanswer
 

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
n°1952473
Joel F
Real men use unique_ptr
Posté le 22-12-2009 à 17:00:06  profilanswer
 

uh oui , c'ets la base basique :
 

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

n°1952478
toonj
Posté le 22-12-2009 à 17:08:52  profilanswer
 

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é 3 fois
n°1952612
__tomjost
c'est un pseudo !
Posté le 22-12-2009 à 23:13:22  profilanswer
 

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
n°1952625
__tomjost
c'est un pseudo !
Posté le 23-12-2009 à 00:09:38  profilanswer
 

__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  


n°1952626
bjone
Insert booze to continue
Posté le 23-12-2009 à 00:10:57  profilanswer
 

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.

n°1952653
toonj
Posté le 23-12-2009 à 08:55:01  profilanswer
 

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;
  6.      Displayable _currentDisplay;
  7.      Computable _currentCompute;
  9.      Object(Displayable display, Computable compute) {_currentDisplay = display; _ currentCompute = compute;}
  11.      void display() {_currentDisplay.display(this);}
  12.      void compute() {_currentCompute.compute(this);}
  13.    };
  18. class Display
  19. {
  20.   public virtual void display(Object) = 0;
  21. };
  22. class Display2D : public Display
  23. {
  24.    void display(Object){//Affichage 2D}
  25. };
  26. class Display3D : public Display
  27. {
  28.    void display(Object){//Affichage 3D}
  29. };
  32. class Computable
  33. {
  34.    virtual void compute(Object){....};
  35. };


 
d'autres idées, ou des commentaires ?


Message édité par toonj le 23-12-2009 à 08:56:02
n°1952654
Joel F
Real men use unique_ptr
Posté le 23-12-2009 à 08:57:53  profilanswer
 

oui c'est pas mal ça.

n°1952676
Polo37
Posté le 23-12-2009 à 10:19:18  profilanswer
 

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

mood
Publicité
Posté le 23-12-2009 à 10:19:18  profilanswer
 

n°1952690
toonj
Posté le 23-12-2009 à 10:31:15  profilanswer
 

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

n°1952731
breizhbugs
Posté le 23-12-2009 à 11:30:57  profilanswer
 

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 ?

n°1952752
bjone
Insert booze to continue
Posté le 23-12-2009 à 12:51:00  profilanswer
 

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
n°1952930
__tomjost
c'est un pseudo !
Posté le 23-12-2009 à 22:21:14  profilanswer
 

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: ]


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

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

 

Sujets relatifs
Triangle en CProblème suppression accents [RESOLU]
RESOLU Redirection htacces et sous domaine[Résolu]Caractères spéciaux et blancs à retirer
[SGBD] [semi-résolu] Comment organiser mes données de façon optimale ?[VBscript] comparaison de chaine/filtre(résolu)
[C#] (RESOLU) GetSchemaTable trop de champs ![RESOLU]Serialize de session/ IE ? :/
[Résolu] Copier la structure d'un site 
Plus de sujets relatifs à : [Resolu][C++] Question Architecture avec interface multiple

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.068 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR