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.

[Marty69]

Wow ! plein d'infos ! ça m'a l'air très intéressant, mais je ne suis malheureusement pas assez calé pour en comprendre toutes les subtilités !
Je m'y remet dès demain

[Marty69]

So here i am !

i have created 3 Printer derived class. I have created a static class in Printer class to instanciate each printer type.

Printer Class .h :

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
#include "ofMain.h"
#include "defines.h"
#include "thermalPrinter.h"
#include "cupsPrinter.h"
#include "instaxPrinter.h"
 
class Printer
{
public:    
    Printer();
    virtual ~Printer();
 
    static Printer * create(int type);
 
    virtual void print() = 0;
};

Printer Class .cpp :

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
#include "printer.h"
 
Printer * Printer::create(int type) {
    switch (type) {
        case PRINTER_THERMAL:
            return new ThermalPrinter();
            break;
        case PRINTER_INSTAX:
            return new InstaxPrinter();
            break;
        case PRINTER_CUPS:
            return new CupsPrinter();
            break;
        default:
            break;
    }
}
 
Printer::Printer() {
 
}
 
Printer::~Printer() {
 
}
 
void Printer::print() {
 
}

i get errors in every return lines saying

Cannot initialize return object of type 'Printer *' with an rvalue of type 'ThermalPrinter *'
Cannot initialize return object of type 'Printer *' with an rvalue of type 'CupsPrinter *'
Cannot initialize return object of type 'Printer *' with an rvalue of type 'InstaxPrinter *'

well that sounds fair... but shouldn't the base class handle those requirements ?

[Pyramidev]

Bonjour,

A mon avis, tu as oublié d'écrire :
class ThermalPrinter : public Printer
{
// code...
};

D'ailleurs, si tu l'avais fait, cela aurait provoqué des erreurs, car il y a un problème avec tes inclusions :
Ce sont les entêtes des classes qui dérivent de Printer qui doivent inclure l'entête de la classe Printer, pas le contraire.
Par contre, ton Printer.cpp peut inclure les entêtes des classes qui dérivent de Printer.

Je conseille la lecture du lien suivant :
http://www.cplusplus.com/forum/articles/10627/

[Marty69]

Merci pour ta réponse...

Ceci dit je dois être un peu fatigué, mais il me semble bien avoir tout ce que tu dis :
- les classes dérivées incluent bien printer.h
- printer.h inclue les classes dérivées (pas le .cpp)
- mes classes dérivées sont bien mentionnées comme héritant de la classe Printer

[dalfab]

- printer.h inclue les classes dérivées (pas le .cpp)

Non, c'est l'inverse qu'il faut faire.
printer.h doit être inclus par les entêtes des dérivées, il ne peut donc pas inclure leurs entêtes. Cela provoque une lecture incomplète des entête et est la cause de ton problème.
Par contre le .cpp qui contient la factory doit tout inclure.

[Marty69]

ok...
J'avais tendence à croire que tout devais résider dans le .h, que les .cpp tiraient leurs besoins des headers et que les doublons, conflits etc étaient gérés par le compilateur

[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.

[Ehonn]

Mais le coût d'un objet qui traîne en mémoire, ça on est prêt à le payer ?

?
(Il s'agit d'une philosophie, pas d'une règle absolue.)

Arrêtons.. cite moi un cas d'utilisation justifiée d'un destructeur non virtuel dans une classe de base.

Lorsque tu n'utilises que la classe de base.
Lorsque le type dynamique est le même que le type statique de la variable qui récupère la responsabilité mémoire.

Après, je peux comprendre que le choix par défaut ne convienne pas à tout le monde.

[Matt_Houston]

La belle affaire, c'est donc justifié lorsque :

• il n'y a pas d'héritage : MOTO ;
• le compilateur a les moyens de s'en rendre compte.

[Ehonn]

La belle affaire, c'est donc justifié lorsque :

• il n'y a pas d'héritage : MOTO ;
• le compilateur a les moyens de s'en rendre compte.

(Les choses évidentes ne sont pas forcément injustifiées )

Pas tout à fait, il y a de l'héritage (polymorphisme d'inclusion) ici :
Fonction :

Code :

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

void f(base_t const & b) { b.fct(); }

Utilisation :

Code :

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

1
2
derived_t d;
f(d);

Le souci vient uniquement lorsque l'appel du destructeur doit être virtual comme dans cet exemple :

Code :

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

std::unique_ptr<base_t> p = std::make_unique<derived_t>();

Et encore, pour être plus exact, il y aura un souci si derived_t ajoute des données membres qui ont un destructeur non vide (ou que ces données membres ont un destructeur non vides, etc).

J'insiste sur fait qu'il s'agit d'un choix par défaut et que je comprend qu'il ne convienne pas à tout le monde.
Cependant, j'en profite pour rajouter que, à titre personnel, je n'ai jamais eu besoin d'utiliser le polymorphisme d'inclusion
et que la programmation générique m'a suffit jusqu'à présent.

[koala01]

Salut,
De manière générale, le respect du SRP et une approche réellement orientée sur les services attendu devrait pouvoir te tirer de beaucoup de mauvais pas.

Ainsi, on envisage le fait qu'une imprimante doit... pouvoir imprimer un document

Si bien que ta classe de base a de bonne chances de ressembler à

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 Printer{
public:
    /* pour le respect de la sémantique d'entité */
    Printer(Printer const & ) = delete;
    Printer & operator=(Printer const &) = delete;
    /* pour pouvoir détruire n'importe quel type d'imprimante connue comme étant
     * une imprimante "sans autre précision"
     */
    virtual ~Printer() = default;
    /* Le principal service que l'on attend de la part de l'imprimante est
     * ... d'imprimer un document
     */
    void Print(Document const & ) ; 
}

Mais on se rend compte que l'impression d'un document peut en réalité nécessiter trois étapes distinctes :

1. l'ouverture d'une communication
2. l'impression en elle même et
3. la fermeture de la communication

Et, bien sur, chaque type spécifique d'imprimante a de bonne chance de faire ces trois actions "à sa propre sauce" (entre autre, certains peuvent ne pas avoir à ouvrir -- et donc à fermer -- la communication).

L'idéal est alors d'utiliser le principe dit du NVI pour introduire les point de variations propres à chaque type d'imprimante, ce qui nous inciterait à transformer notre classe printer pour qu'elle prenne une forme proche de

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
class Printer{
public:
    /* pour le respect de la sémantique d'entité */
    Printer(Printer const & ) = delete;
    Printer & operator=(Printer const &) = delete;
    /* pour pouvoir détruire n'importe quel type d'imprimante connue comme étant
     * une imprimante "sans autre précision"
     */
    virtual ~Printer() = default;
    /* Le principal service que l'on attend de la part de l'imprimante est
     * ... d'imprimer un document
     */
    void print(Document const & doc){
        openChannel(); //ouvrir le canal de communication (quel qu'il soit)
        doPrint(doc); // l'impression proprement dite
        closeChannel(); // fermer le canal de communication une fois l'impression terminée
private:
 
    virtual void openChannel() ;
    virtual void doPrint() = 0;
    virtual  void closeChannel();
    }
};
 
void Printer::openChannel(){
}
void Printer::closeChannel(){
}

quant à l'implémentation de ces trois fonctions, il y en a deux (openChannel et de closeChannel) pour lesquels on peut définir un comportement par déraut "acceptable" qui consisterait à ... ne rien faire.

En effet, il se peut que l'on trouve une imprimante qui n'ait absolument pas besoin d'ouvrir (et donc de fermer) un canal de communication. Il serait donc "dommage" d'obliger le développeur à implémenter ces fonctions alors... qu'elles ne font rien !!!

Par contre, il semble totalement impossible de fournir un comportement par défaut pour l'impression en elle-même. Nous devons donc déclarer cette fonction comme étant virtuelle pure

Ensuite, nous voudrons sans doute pouvoir interroger l'imprimante sur son état qui peut être:

• en attente d'un travail
• en cours d'impression
• en erreur (ex: un bourrage papier ou autre).
• j'en oublie peut être

Et ca, c'est aussi un service commun à "n'importe quel type d'imprimante".

Nous pourrions donc sans doute modifier encore notre classe Printer pour lui donner une forme proche de

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
47
48
49
50
51
52
53
54
55
56
57
class Printer{
public:
    enum Status{
        error,
        waiting,
        printing
    }
    Printer():status_{waiting}{
    }
    /* pour le respect de la sémantique d'entité */
    Printer(Printer const & ) = delete;
    Printer & operator=(Printer const &) = delete;
    /* pour pouvoir détruire n'importe quel type d'imprimante connue comme étant
     * une imprimante "sans autre précision"
     */
    virtual ~Printer() = default;
    /* Le principal service que l'on attend de la part de l'imprimante est
     * ... d'imprimer un document
     */
    void print(Document const & doc){
        switch(status_){
            case error:
                throw std::runtime_error("please correct hardware problems first");
            case waiting :
                status_= printing;
                openChannel();
                doPrint(doc);
                closeChannel();
                status_ = waiting;
            case printing:
                throw std::runtime_error("please wait for current job ends");
        }
    }
    Status status() const{
        return status_;
    }
    bool isWaiting() const{
        return status_ == waiting;
    }
    bool isPrinting() const{
        return status_ == printing;
    }
    bool isInErrorState() const{
        return status_ == error;
    }
private:
 
    virtual void openChannel() ;
    virtual void doPrint(Document const &) = 0;
    virtual  void closeChannel();
    Status status_;
};
 
void Printer::openChannel(){
}
void Printer::closeChannel(){
}

Bien sur, tu peut sans doute t'attendre à encore d'autres services de la part d'une "imprimante générique"... je te laisse juge desquels et de comment les mettre en oeuvre

Mais bon, un fois que ceci est fait, tu pourras faire hériter les différents types d'imprimante de ta classe Printer, et au final, tu pourrais dresser une liste d'imprimantes sous une forme proche de

Code :

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

1
2
3
std::vector<std::unique_ptr<Printer>> allPrinters;
allPrinters.emplace_back(std::make_unique <CupsPrinter>(/* paramètres nécessaires aux imprimantes CUPS */));
allPrinters.emplace_back(std::make_unique<WiFiPrinter>(/* paramètre nécessaires */));

Et tu pourrais, par exemple, utiliser cette liste pour lancer l'impression du même document sur "toutes les imprimantes en attente", sous une forme qui serait proche de

Code :

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

1
2
3
4
5
6
/* soit doc est le document à imprimer */
for(auto & p : allPrinters){
    /* on ne veut que les imprimantes en attente */
    if(p.get()->isWaiting())
        p.get()->print(doc);
}

Sympa, non ??

Tu n'as même plus besoin de t'inquiéter de savoir "tout ce qui doit être fait" avant (ou après) de pouvoir imprimer ton document, car l'imprimante le sais bien mieux que toi

[jo_link_noir]

@Matt_Houston: Concernant l'héritage et le destructeur non virtuelle, il y a plusieurs situations non-évidente aux premiers abords:

- Les techniques de méta-programmation. Std::tuple utilise massivement de l'héritage et n'est pas virtuel.
- L'optimisation mémoire avec de la composition de type vide (ebo), utilisé par unique_ptr et shared_ptr (à travers un std::tuple) et n'importe quel conteneur de la stl qui utilise un allocateur.
- Le découpage de responsabilité pour bénéficier du RFID: std::_Vector_base, _List_base, etc (nom dépendant de l'implémentation) s'occupent de la gestion mémoire alors que les classes filles (std::vector, std::list) s'occupent de l'initialisation de la mémoire. Dans ce genre de cas, c'est un héritage privé, au pire protégé.
- CRTP ou un système de mixins.
- Pour stocker un type uniforme dans une collection en sachant exactement le type réel utilisé (un pattern visiteur par exemple).

[jblecanard]

Hello tous

Pour continuer sur la lancée de Koala, plutôt que d'utiliser un pattern NVI, j'aurais plutôt fait du RAII jusqu'au bout. C'est à dire, la classe Printer n'a qu'une seule fonction membre createPrintTask qui renvoie std::unique_ptr<PrinterTask>. Cet objet ouvre la communication dans son constructeur, propose ce qu'il faut pour imprimer (fonction membre print ?) et ferme la communication dans son destructeur. De cette manière, on utilise vraiment l'aspect acquisition de ressource propre au RAII et on peut se passer de lister les particularités des imprimantes dans l'interface (même si c'est en privé, ça reste un couplage).

Ou alors on encapsule carrément l'ouverture et la fermeture des canaux dans les constructeurs/destructeurs des imprimantes. Là il faut connaître le context plus précisément pour faire le bon choix.

Ca reste du chipotage, les deux solutions fonctionnent.

[Marty69]

Bon j'ai décroché depuis longtemps hein ! mais je suis la conversation avec grand intérêt.
Merci Koala pour cette belle démonstration

J'en suis encore à débugguer parce que évidement quand on manipule (mal) les pointeurs, on se mange des vilains BAD_ACCESS !!! (enfin moi en tout cas !)