Discussion :

[Marty69]

hello,

J'utilise openFrameworks mais j'ai une question orientée C++ plus que framework

J'ai une appli qui utilise une imprimante. Cette imprimante peut être de plusieurs type :
- standard via CUPS en appelant une commande système
- imprimante WiFi
- Imprimante thermique sur port série via USB en utilisant un addon (ofxThermalPrinter)

J'ai pas mal lu à propos de l'héritage et le polymorphisme mais des subtilités m'échappent. Je ne suis pas trop familier avec ces notions ne les utilisant pas très souvent. Mais dans mon cas, cela semble recommandé !

donc j'imagine utiliser des classes de la sorte :
- BasePrinter class
- PrinterCUPS class dérivée de BasePrinter
- PrinterWIFI class dérivée de BasePrinter
- PrinterThermal class dérivée de BasePrinter et ofxThermalPrinter

les contraintes :
- toutes les imprimantes ont une méthode print()
- seules les imprimantes WiFi et Série ont une méthode close()

Ce que je vois dans mon cas c'est que je n'aurais pas besoin de BasePrinter puisque toutes les imprimantes fonctionneront différemment. J'imagine donc que je dois utiliser une classe abstraite ?

j'ai donc dans mon cas (cas uniquement pour ThermalPrinter)

Code :

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

1
2
3
4
5
6
7
8
   class Printer
    {
    public:    
        Printer() {};
        virtual ~Printer() {};
 
        virtual void print() = 0;
    }

-

Code :

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

1
2
3
4
5
6
7
8
9
10
11
   #include <printer.h>
    #include <ofxThermalPrinter.h>
 
    class ThermalPrinter : public Printer, public ofxThermalPrinter {
    public:
        ThermalPrinter();
        virtual ~ThermalPrinter();
 
        virtual void print();
 
    };

Ais-je besoin d'utiliser des pointeurs ?
Comment utiliser / instancier ces imprimantes ? dois-je passer par BasePrinter ou les classes dérivées ?

toute aide serait le bienvenu !

Merci beaucoup !

[dalfab]

Ce que je vois dans mon cas c'est que je n'aurais pas besoin de BasePrinter puisque toutes les imprimantes fonctionneront différemment. J'imagine donc que je dois utiliser une classe abstraite ?

Tout à fait.

Ais-je besoin d'utiliser des pointeurs ?

Dès que l'on souhaite utiliser une capacité commune, on ne peut le faire que par pointeur nu, par pointeur 'intelligent' ou par référence.

Comment utiliser / instancier ces imprimantes ? dois-je passer par BasePrinter ou les classes dérivées ?

On doit créer une classe dérivée et on pourra s'en servir via pointeur ou référence de type BasePrinter

Code :

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

1
2
3
4
// exemple avec pointeur intelligent
std::shared_ptr<Printer> printer = std::make_shared<ThermalPrinter>(/*paramètres constructeur ThermalPrinter*/);
 
printer->print();

Mais attention, s'il existe des fonctions spécifiques à un type, on doit revenir au type dérivé pour pouvoir l'utiliser.
Si on prend la fonction close(), où faut-il la déclarer? Pas dans BasePrinter car ThermalPrinter n'a pas cela. Il faut s'intéresser au service attendu. Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
PrinterWIFI prtrwifi();
prtrwifi.fctSpecifique();
effectuerTraitement( prtrwifi ); // effectuera des actions complexes mais n'utilisera que baseprinter.print()
prtrwifi.fctSpecique();
prtrwifi.close();
 
// avec
void effectuerTraitement( BasePrinter &bp ) { // ici on utilise une référence
   ...
   bp.print();
   ...
}

Dans ce cas, l'héritage joue pleinement son rôle.
Mais si à un moment pendant effectuerTraitement(), on a une action dépendant du type d'imprimante, tout l'intérêt de l'héritage disparaît.

[Marty69]

Merci beaucoup pour toutes ces précisions.
Evidement je n'ai pas tout compris, mais ça va rentrer

Dès que l'on souhaite utiliser une capacité commune, on ne peut le faire que par pointeur nu, par pointeur 'intelligent' ou par référence.

qu'appelles tu capacité commune ?
Aussi j'ai bien lu au fil de mes recherches que dans certains cas il faut utiliser les pointeurs (ou références). D'ou ma question. Ce que je ne saisis pas c'est pourquoi ?

Et aussi cette info comme quoi un constructeur ne peut être virtuel mais qu'il est bon d'avoir le destructeur virtuel...

Il faut s'intéresser au service attendu. Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
PrinterWIFI prtrwifi();
prtrwifi.fctSpecifique();
effectuerTraitement( prtrwifi ); // effectuera des actions complexes mais n'utilisera que baseprinter.print()
prtrwifi.fctSpecique();
prtrwifi.close();
 
// avec
void effectuerTraitement( BasePrinter &bp ) { // ici on utilise une référence
   ...
   bp.print();
   ...
}

Dans ce cas, l'héritage joue pleinement son rôle.
Mais si à un moment pendant effectuerTraitement(), on a une action dépendant du type d'imprimante, tout l'intérêt de l'héritage disparaît.

Ca y est, je suis perdu (ah ces pointeurs, c'est mystique !)

Enfin, comment faire pour choisir le bon type d'imprimante (l'instanciation je veux dire) ?
- faut il filtrer et appeler manuellement la bonne classe dérivée ?
- peut on faire en sorte que la bonne classe dérivée soit appelée automatiquement, en fonction des arguments passés au constructeur par exemple ?
- j'ai lu des choses à propos des Factory (que j'ai encore du mal à intégrer). Est-ce une façon d'appeler la bonne classe en fonction des besoins ?

Merci encore pour ces précisions

[Matt_Houston]

Mais attention, s'il existe des fonctions spécifiques à un type, on doit revenir au type dérivé pour pouvoir l'utiliser.
Si on prend la fonction close(), où faut-il la déclarer?

Il est aussi envisageable de définir close comme fonction vide dans la classe de base puis de la redéfinir dans les classes dérivées qui en ont le besoin.

qu'appelles tu capacité commune ?

Une capacité décrite par les données et méthodes déclarées dans la classe de base, et donc commune aux classes dérivées.

Aussi j'ai bien lu au fil de mes recherches que dans certains cas il faut utiliser les pointeurs (ou références). D'ou ma question. Ce que je ne saisis pas c'est pourquoi ?

La taille du type dérivé peut être plus grande que celle du type de base, il n'est pas possible de passer par un objet dont la taille est connue à la compilation. On passe donc par des références (pointeurs ou références C++) qui permettent de s'affranchir de ces contraintes. Cela permet entre autre choses de maintenir des tableaux ou std::vector de BasePrinter * qui référencent des objets de taille différente.

De plus, lorsque la classe de base est abstraite (c'est ton cas), il est carrément impossible de l'instancier.

Enfin, comment faire pour choisir le bon type d'imprimante (l'instanciation je veux dire) ?
- faut il filtrer et appeler manuellement la bonne classe dérivée ?
- peut on faire en sorte que la bonne classe dérivée soit appelée automatiquement, en fonction des arguments passés au constructeur par exemple ?
- j'ai lu des choses à propos des Factory (que j'ai encore du mal à intégrer). Est-ce une façon d'appeler la bonne classe en fonction des besoins ?

Tu ne peux pas choisir le type à la construction depuis la classe instanciée, cela doit être délégué vers l'extérieur. Selon ton besoin, ça peut aussi bien être le rôle d'une fonction déclarée static au sein de cette même interface, ou bien réalisé par une factory dédiée effectivement qui reçoit des arguments et te retourne un pointeur vers la classe de base.

Et aussi cette info comme quoi un constructeur ne peut être virtuel mais qu'il est bon d'avoir le destructeur virtuel...

Si le destructeur n'est pas virtuel, les ressources spécifiques aux classes dérivées ne sont pas proprement détruites lors d'un delete ptr (ptr étant un pointeur vers la classe de base). Oui ce devrait être automatique, mais c'est au programmeur de s'en assurer. C'est une des nombreuses contraintes random de ce langage.

[Ehonn]

Si le destructeur n'est pas virtuel, les ressources spécifiques aux classes dérivées ne sont pas proprement détruites lors d'un delete ptr (ptr étant un pointeur vers la classe de base). Oui ce devrait être automatique, mais c'est au programmeur de s'en assurer. C'est une des nombreuses contraintes random de ce langage.

Non, ça ne devrait pas être automatique. On ne veut pas toujours payer le coût d'un appel de fonction passant par la table virtual.
Le C++ a une philosophie " pay for what you use ".

[Médinoc]

La recommandation de Herb Sutter pour les destructeurs d'une classe destinée à être dérivée, c'est qu'ils soient soit protected et non-virtuels (ce qui empêche d'essayer de détruire l'objet via un pointeur vers la classe de base), soit publics et virtuels.
L'inconvénient dans le premier cas, c'est que ça oblige à forcer une distinction entre "classe supposée être dérivée" et "classe supposée être instanciée directement" (c'est-à-dire d'un côté les classes abstraites (ou avec constructeur protected) que l'on n'est jamais censé instancier, de l'autre les classes concrètes "feuilles" dont on n'est pas censé dériver du tout; et cette distinction est une des "recommandations" de How to Write Unmaintainable Code, ce qui la rend suspecte à mes yeux.

[Matt_Houston]

Non, ça ne devrait pas être automatique. On ne veut pas toujours payer le coût d'un appel de fonction passant par la table virtual.
Le C++ a une philosophie " pay for what you use ".

Mais le coût d'un objet qui traîne en mémoire, ça on est prêt à le payer ? Arrêtons.. cite moi un cas d'utilisation justifiée d'un destructeur non virtuel dans une classe de base.