Discussion :

[Porkipic]

Bonjour,

Nouveau problème dû au polymorphisme (c'est compliqué ce truc). Voici donc le problème :

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
 
Class mere{
     virtual void fonction1(int arg) = 0;
     void fonction2(double arg);
}
 
Class fille : public mere {
     void fonction1(int arg);
     int toto();
}
 
main{
     unique_ptr<mere> merePtr (fille());  //Code (faux ?) à titre d'exemple pour montrer que je travaille avec un pointeur.
     merePtr.get()->fonction1(10);     //Ca fonctionnne
     merePtr.get()->fonction2(3.14);  //Ca fonctionnne
     merePtr.get()->toto();               //Ca ne fonctionne pas
}

Y'a t'il une astuce pour appeler une méthode fille via la fonction mere sans que celle ci ne sache les méthodes spécifiques aux classes filles.
Pour info certaines méthodes des classes filles seront communes, d'autres spécifiques à chaque fille.

La méthode brutale que j'ai trouvé sur le net serait de déclarer chaque méthode spécifique de chaque classe fille dans la classe mere, ce qui n'est pas mon but. Je voudrais pouvoir ajouter de nouvelles classes fille (qui auront aussi des méthodes spécifiques) sans avoir à retravailler la classe mere.
Est-ce possible ?

Question subsidière : Quelle est la différence entre *merePtr et merePtr.get() ?

[bacelar]

C'est une erreur de conception.
S'il te faut utiliser les méthodes de la classe fille depuis un élément dans un conteneur de la classe mère, c'est que vous auriez du utiliser un conteneur de la classe fille.

C'est quoi, concrètement des classes mères et filles ?

[Porkipic]

Voici le prototype de la classe mere :

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
class GPSSentence {
    public:
        virtual ~GPSSentence();
        GPSSentence();
        GPSSentence(std::string type);
 
        virtual void setType(std::string type)=0;
 
        unsigned short int getNbField() const;
        std::string getType() const;
 
    protected:
 
        unsigned short int nbField; 
        std::string type;
 
};

et celui de la classe fille :

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
class GPGAA : public GPSSentence{
    public:
        GPGAA();
        virtual ~GPGAA();
 
        Time getTime();
        Latitude getLatitude();
        Longitude getLongitude();
        unsigned int getFixQuality();
        unsigned int getNbOfSat();
        double getHDilution();
        Altitude getSeaAltitude();
        Altitude getWsgAltitude();        
 
    protected:
        void setType(std::string type);
        void setTime(Time time);
        void setLatitude(Latitude latitude);
        void setLongitude(Longitude longitude);
        void setFixQuality(unsigned int fixQuality);
        void setNbOfSat(unsigned int nbOfSat);
        void setHDilution(double hDilution);
        void setSeaAltitude(Altitude seaAltitude);
        void setWsgAltitude(Altitude wsgAltitude);
 
    private:
        Time fixTime;
        Latitude latitude;
        Longitude longitude;
        unsigned int fixQuality;
        unsigned int nbOfSat;
        double hDilution;
        Altitude seaAltitude;
        Altitude wsgAltitude;
 
};

Je vais donc énoncer clairement mon objectif, ce sera plus simple.
-Décortiquer plusieurs types de trames GPS, qui ont des champs différents.
-Stocker ces champs dans des variables de classe
-utiliser des méthodes spécifiques à chaque trame sans savoir à l'avance quelle type de trame je récupère.

Je pensais qu'en faisant appel à une méthode inconnue de la classe mere, celle-ci regarderait si ses filles ont la méthode demandée et l’appellerais.
Cependant plus je réfléchi et plus cela est illogique. Comment la classe mere pourrait-elle faire un traitement quelconque sur une chose totalement inconnue d'elle ?

Si vous avez une technique qui résolve mon problème et soit évolutive (possibilité d'ajouter des types de trame en ajoutant simplement la classe correspondante sans toucher au reste du code), je suis preneur.

Le dynamic_cast a l'air de faire ce que je souhaite, mais n'a pas l'air d'être trop recommander. Qu'en pensez-vous ?

[bacelar]

Comment la classe mere pourrait-elle faire un traitement quelconque sur une chose totalement inconnue d'elle ?

Utilisation de typage dynamique, non disponible en C++ ou des mécanismes de dispatching évolués comme en Objective-C ou le late-binding COM.
Mais rien avec du C++ de base.

soit évolutive (possibilité d'ajouter des types de trame en ajoutant simplement la classe correspondante sans toucher au reste du code), je suis preneur.

Evolutif selon quel axe ???
Si vous utilisez les fonctionnalités des nouvelles classes dans du code client de ces classes, cela veut dire que vous devez modifier votre code client avec l'arrivé de nouvelle classe. Et ça, c'est un problème de conception à l'extérieur de la hiérarchie des classes.

Le dynamic_cast a l'air de faire ce que je souhaite, mais n'a pas l'air d'être trop recommander. Qu'en pensez-vous ? .

Pareil, c'est faisable, mais cela ne fera que masquer les erreurs de conception qu'il serait plus efficace de corriger à la source.

-Décortiquer plusieurs types de trames GPS, qui ont des champs différents.
-Stocker ces champs dans des variables de classe

Je vous laisse regarder la littérature sur les différents Design Pattern de création (Factory Template, Factory Method, Builder, etc...)

-utiliser des méthodes spécifiques à chaque trame sans savoir à l'avance quelle type de trame je récupère.

C'est là qu'est l'erreur de conception, il faut concevoir le mode d'interaction entre le code client et la hiérarchie de classe.

[r0d]

Bonjour,

l'erreur qui est faite ici est de considérer une classe comme un conteneur, et non comme un service. La présence de tous ces get et set symbolisent bien le problème.
C++ n'est pas du C dans lequel on a injecté quelques mécanismes "orienté objet". C++ est un langage propre, qui a sa philosophie propre. Une des façons de voir cette philosophie consiste à considérer les objets en tant que services. C'est à dire que le but de l'objet n'est pas de contenir de l'information (même s'il peut en contenir, ce n'est pas son but final), mais d'effectuer une opération (un service).

Prenons un exemple: on souhaite afficher une image à l'écran. La première approche consiste à déclarer une classe Image qui contient les points, et une fonction affiche() qui parcours les points de l'image et les affiche:

Code :

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

1
2
3
4
5
6
7
8
9
struct Image
{
   std::vector<Point> points;
};
 
void affiche(const Image & image)
{
   foreach( /* point in image.points */ ) my_graphic_li.draw(point);
}

Cette façon de faire correspond à ce que vous essayez de faire dans votre code. Elle n'est pas bonne dans le contexte du c++ pour tout un tas de raison, notamment parce que C++ est un langage compilé qui n'a aucune information sur le code généré après la compilation, en particulier sur les types. Ainsi donc, dans l'exemple ci-dessus, si vous voulez changer quoi que ce soit (type de points, cible de l'affichage, bibliothèque utilisée, ...), il faut refaire tout le code.

La bonne façon de faire est de ne pas considérer Image comme un objet qui contient des données, mais comme un objet qui rend un service, ici le service est l'affichage. Le code ci-dessus devient alors:

Code :

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

1
2
3
4
5
6
struct Image
{
   void Affiche(Context & context) { /*foreach .... context.draw_point(point) */ }
private/protected:
   std::vector<Point> points;
};

La différence, qui parait subtile sur un si petit bout de code, est en fait cruciale: c'est l'objet qui s'occupe d'implémenter la fonctionnalité qui légitime son existence.
Un des gros avantages de cette méthode, c'est que votre objet va définir une liste de services (ensemble des fonctions publiques), qu'on appelle l'interface. L'interface est un concept fondamental en poo, et si l'interface d'un objet est bien pensée, alors ça permet tout un tas de choses très pratiques, notamment la substituabilité (cf. LSP).
Un avantage moins théorique, plus pratique, c'est qu'en c++, il est très difficile d'avoir des informations sur les types, mais en revanche on connait les interfaces des classes avant même la compilation. On laisse donc à chaque classe le soin (la responsabilité) de faire ce qu'elle a à faire.

[Porkipic]

r0d,

Votre explication m'a permis de comprendre mon erreur. J'utilise bien mes classes pour stocker les données et j'essaye en fait d’utiliser l'interface comme un morceau de classe et de la "concaténer" à une autre. Quelque chose du genre classe mère+classe fille = classe complète, alors qu'une interface n'a l'air que d'être un sommaire des fonction disponibles (et obligatoires ?) que les classes filles doivent implémenter.
Cela m'amène donc à la question suivante : si les données ne sont pas stockées dans les classes, où sont elles ?

J'essaie de faire un programme qui décortique des trames GPS qui sont reçues sous ce format :
$GPGGA,130303.00,4910.28659,N,00521.52083,E,1,07,1.06,207.9,M,46.7,M,,*51
ou
$GPVTG,,T,,M,0.064,N,0.118,K,A*29
Ce sont donc des string à peu près inutilisables en tant que telles. Je souhaite donc pouvoir les découper et les organiser correctement en faisant des objets (type, latitude, longitude, heure, ...) regroupés dans une classe.

Si je suis bien votre raisonnement, je devrais avoir une classe (singleton ?) qui effectue le découpage en fonction du type de trame (GPGAA, GPVTG, etc ...), mais ensuite, que faire des données ainsi recueillies ? Je dois bien pouvoir les stocker quelque part pour les exploiter ... Sous quelle forme représenter des données si le rôle des classes n'est que de fournir une service (formatage, transformation et vérification dans mon cas) et non de stocker les données.

Les exemples fournis dans tous les livres montrent bien cette notion de service : le cheval hennit, le chat miaule, etc. Mais dans ce cas, pourquoi mettre des variables dans les classes (couleur, vitesse, ...) si elles ne sont pas faites pour stocker des données ? Représenter les données sous une forme exploitable n'est-il donc pas un service de "formatage" et de mise à disposition (d'où les get et set) ?

Je ne remet pas en cause la justesse de votre commentaire, je cherche simplement à comprendre le fond et la forme de la POO.

C'est décourageant, plus on gratte, plus on s'enfonce.

[JolyLoic]

Ce qui est important, c'est de déterminer ce qui est commun, et ce qui diffère.
Par exemple, j'ai l'impression que ce qui est commun dans ton cas, c'est (je manque d'infos pour pousser le raisonnement assez loin) :
- Une trame peut être lue
- On peut effectuer telle ou telle action sur une trame (je ne sais pas s'il y a des actions communes, ou si le fait d'avoir des actions est la seule chose commune)
Et ce qui diffère :
- La manière dont la trame est lue
- Certaines actions à effectuer sur la trame

Dans la classe de base, on ne peut mettre que des points communs. Et les points qui diffèrent, on aimerait bien qu'ils ne soient jamais utilisés depuis la classe de base. Ce qui signifie en général qu'ils se limitent :
- À avoir un rôle à la création des objets, quand on connait leur vrai type, avant qu'on ne le manipule plus que par la classe de base
- À servir à implémenter différemment des comportements communs (donc à implémenter une redéfinition de fonction virtuelle)

Si tu nous dit ce que tu aimerais faire avec chaque type de trame, on pourra peut-être pousser plus loin le raisonnement.

[Porkipic]

J'ai différents types de trame GPS (6 différents):
$GPGGA,130303.00,4910.28659,N,00521.52083,E,1,07,1.06,207.9,M,46.7,M,,*51
ou
$GPGSA,A,3,31,01,23,04,06,17,32,,,,,,2.39,1.06,2.14*0D

Ils me sont fournis via un fichier texte, donc sous forme de string comme ci-dessus.

Une classe singleton (GPSAnalyser) reçoit cette string et fais le travail suivant :
- détection du type de trame grâce au premier "mot" (GPGGA, GPGSA, etc)
- création d'un objet du type requis (GPGGA, GPGSA, etc)
- renseignement des différentes variables de l'objet avec les "mots" récupérés
- renvoi d'un pointeur de l'objet créé

Et c'est la que ça coince. Je ne peut pas prédire quel objet ressortira de GPSAnalyser, il me faut donc un objet générique qui puisse être vu comme un GPGGA, un GPGSA, etc
Comme vous pouvez le constater, les trames ne sont pas identiques et contiennent des informations différentes, de plus, le nombre de "mots" contenus est aussi différent.
Le premier mot de la trame GPGGA contient l'heure de réception de la trame (130303.00) que je stocke sous forme d'un objet Time.
Le premier mot de la trame GPGSA contient le mode de sélection du GPS ("A" = auto, "M"=manuel) qui est un char.

Donc même si je mettait des méthodes au nom identique dans les classes GP*** (getVar1(), getVar2()) afin de pouvoir faire une interface, cela serait impossible pour 2 raisons:
- le nombre de méthodes diffère. Mettre une méthode getVar12() sur une classe GP*** qui ne compte que 8 variables me parait assez bancal.
- le type d'objet retourné par ces méthode est différent Time, char, int, etc ...

Je cherche donc une technique qui permette à GPSAnalyser de renvoyer un objet générique qui puisse être reconnu comme un GPGAA, un GPGSA, ou autre.
Les classes GP*** n'ont en commun qu'une chose : la méthode std::string getType() const qui renvoi une string contenant le type de la trame (qui correspond aussi au type de l'objet).

Pour l'instant, j'arrive à faire fonctionner 2 principes :
- une classe abstraite (unique_ptr<GPSSentence> renvoyé par GPSAnalyser) qui ne me fournit que la méthode getType (normal, c'est la seule commune). Les classes GP*** héritent de cette classe abstraite dont le seul rôle est d'implémenter la méthode std::string getType() const qui est commune à toutes les classes GP***.
- une classe GPSAnalyser qui ne sait me renvoyer qu'un type d'objet GP*** (GPGGA en l’occurrence)

Donc la question à 100 balles :
Comment puis-je faire pour obtenir le comportement souhaité, c'est à dire faire retourner à GPSAnalyser un objet générique et ensuite l'utiliser comme un objet spécifique.

Les choses communes :
- une variable de classe (string type) et la méthode associée getType.
- la manière dont la trame est lue (tâche confiée à un singleton)

Les choses différentes :
- les variables (et type de variable) de classe
- les méthodes d'accès à ces variables

Le but final :

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
int main(int argc, char** argv) {
    GPSSentenceAnalyser& gpsAnalyser = GPSSentenceAnalyser::getInstance();
    string line;
    ifstream file;
    file.open("C:/Users/*****/Desktop/GPSdata.txt");
    if (file.is_open()){
        getline(file, line);
        unique_ptr<GPSSentence> gpsObj = gpsAnalyser.analyse(line);
        cout << gpsObj.get()->getHDilution();   //NE FONCTIONNE PAS, cette méthode n'étant déclarée/implémentée que dans la classe GPGAA
        cout << gpsObj.get()->getType();        //Fonctionne, cette méthode est commune à toutes les classes GP*** et déclarée/implémentée dans la classe abstraite GPSSentence
    }else{
        cout << "File not open" << endl;
    }
    return 0;
}

Donc afficher une variable d'une classe GP*** suite au décorticage de la string "line", ne sachant quel type d'objet est retourné.

[JolyLoic]

Pour l'instant, tu n'as pas vraiment répondu à ma question. Quand tu dis que ce que tu veux, c'est récupérer les variables, c'est probablement faux: Tu ne veux pas récupérer les variables, tu veux faire quelque-chose avec leur valeurs. Et autant les variables disponibles sont différentes d'une trame à l'autre, autant ce que tu veux en faire peut avoir des points communs.

Pour trouver une analogie, si tu devais modéliser des machines à laver, chacune a tout un tas de boutons de fonctionnement différents, en nombre différent, tout un tas de voyant spécifiques. Comment toutes les modéliser ? Et bien en oubliant ces détails d'implémentation, et en te concentrant sur le service fourni. Et ce service, ce n'est pas une liste de boutons: C'est laver le linge. Et quelque soit la machine (même si au final tu veux modéliser un pressing), tu peux trouver des opérations génériques (par exemple, ajouter du linge, démarrer le lavage, être averti qu'il est fini, récupérer le linge).

Peut-être que quelque-chose qui peut t'aider c'est de te places non par du point de vue de tes trames GPS, mais du point de vue du reste de ton programme : À quoi sert-il, pourquoi a-t-il besoin de manipuler des infos GPS, que compte-t-il en faire ?

Par exemple, si ton seul but est l'affichage de la trame, tu fournis juste une fonction membre virtual void display(ostream &destination) = 0; dans la classe de base, tu n'as aucunement besoin d'exposer la moindre variable pour ça.

[r0d]

Cela m'amène donc à la question suivante : si les données ne sont pas stockées dans les classes, où sont elles ?

Je n'ai pas dit qu'une classe ne doit pas contenir des données, j'ai dit que ce n'était pas sont rôle principal, car son rôle principal est de fournir un/des service(s), une/des fonctionnalité(s). Donc oui, une classe peut parfaitement contenir des données.

Je ne sais pas si c'est une bonne chose de dire ça, car j'ai peur de t'embrouiller, mais je crois que ça peut aider pour la compréhension du cas présent (cette histoire de trame): le service rendu par une classe peut être de contenir des données. En vérité c'est assez rare, mais ça peut arriver (c'est souvent pour des raisons de simplification de code). Mais dans ce cas, autant laisser toutes ces données publiques (donc pas d'accesseurs ni de mutateurs).

Et j'en arrive au problème de tes trames. J'avoue que je ne comprend pas bien ce que tu veux faire avec ces trames. Si tu veux juste les stocker, alors laisse-les sous forme de chaîne de caractère, non?

[oodini]

Tes objets devant au final présenter des informations apparemment très différentes, il faut, comme l'ont suggéré plusieurs, te poser la question de ce que tu veux faire de ces trames.
Et tant que des différences subsistent en terme de service demandé, il faut aller plus loin dans le flux d'utilisation.

Et si tes trames n'ont pas grand chose en commun, leur classe de base va se réduire à la portion congrue. Voire à rien.
Une fabrique va lire les premiers caractère, et te renvoyer une instance en fonction du type lu dans la trame.

Par exemple, prenons un scénario stupide.

Tu reçois toutes ces trames sur un canal d'entrée, et tu voudrais les router sur des canaux de sortie différents, selon leur type.

Tu envoies ta trame à la fabrique, qui te renvoie une instance du type correspondant (ou une exception, si elle n'en a pas trouvé).

Ensuite, tu pourrais avoir une fonction surchargée, qui en fonction du type de l'objet qui lui est soumis, envoie l'objet sur le bon canal de sortie.

Ou alors, tu pourrais faire ça en utilisant une fonction membre virtuelle du genre sendToOutput().
Dans ce cas là, ce serait une fonction membre virtuelle pure déclarée dans une classe parente.

Si la trame est compressée en entrée, tu pourrais ajouter une méthode protégée de décompression, virtuelle si le schéma de compression dépend du type.
La décompression serait appelée des constructeurs des classes filles.