Discussion :

[sfarc]

Bonjour,

En utilisant QtDesigner pour créer mes interfaces, j'ai remarqué qu'on pouvait ensuite accéder aux éléments définis dans le designer simplement en faisant :

Code :

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

ui->elementName

On dirait donc que le pointeur sur l'élément est en fait déclaré en "membre public" et non en privé comme on aurait l'habitude de le faire sans le designer.
Est-ce le cas ? Si oui, pourquoi ?

Sinon, peut être que ça équivaut à une sorte de propriété qui appelle derrière les méthodes get/set (mais bon avec exactement le même nom que l'objet ça m'étonnerait) ?

Vu que derrière le fichier ui est un xml, c'est difficile à vérifier..

Merci

[koala01]

Salut,

A priori (du moins, pour ce que je m'en rappelle), tous les membres de ui sont bels et bien publiques.

Cependant, ui est utilisé selon l'idiome dit du "pimple".

C'est à dire que ui sera, de toutes manières, un membre (privé!!!!) du formulaire qui le représente.

Du coup, il n'y a finalement aucun problème d’accessibilité: seules les fonctions publiques du formulaire permettront à l'utilisateur d'accéder, de manière très fine, au contenu de ui

[sfarc]

Salut koala01 et merci pour ton aide

Cependant, ui est utilisé selon l'idiome dit du "pimple".
C'est à dire que ui sera, de toutes manières, un membre (privé!!!!) du formulaire qui le représente.

En fait, l'intérêt que je vois surtout avec l'idiome pimple est l'optimisation du temps de compilation (répercussion moindre lors d'un changement sur l'objet privé pointé plutôt que sur les membres ou méthodes).

Par contre, pour l'accessibilité, à part le fait que je vois pourquoi dans ce cas ça ne pose pas de problèmes (pas d'accès depuis l'extérieur de l'objet qui utilise ce formulaire), je ne comprends pas, plus généralement, l'intérêt de l'utiliser ailleurs ?

[koala01]

En fait, à la base, le pimple idiom est surtout intéressant dés que tu te trouves face à la possibilité d'avoir plusieurs classes spécifiques qui correspondent à une interface similaire: en utilisant uniquement l'interface (donc, en ne connaissant, au niveau de l'utilisateur, que la classe de base), le simple fait de changer le type réel de l'objet pointé par ton pointeur d'implémentation te permet d'adapter ton comportement à ce qui doit être effectivement effectué.

Prenons, par exemple, un système d'affichage (text / OpenGl / DirectX) ou un système de sérialisation d'options (dans les formats Xml / ini de windows / n'importe quel autre format).

Tu peux avoir une classe de base (pour l'affichage ou pour la sérialization des options) strictement identique quel que soit le "format d'entrée" (ou de sortie): La manière dont tu utiliseras les différents système sera basée sur des fonctions telles que draw(), load() ou save().

La seule différence, c'est que ces différentes fonctions réagiront de manière différente en fonction du contexte (text / OpenGL / DirectX // Xml / ini / autre format) dans lequel elles devront travailler.

En changeant simplement le type réel de l'objet pointé, tu changes, purement et simplement, le contexte d'utilisation, ce qui te permet une souplesse beaucoup plus importante, et d'évoluer de manière beaucoup plus facile

[sfarc]

en utilisant uniquement l'interface (donc, en ne connaissant, au niveau de l'utilisateur, que la classe de base), le simple fait de changer le type réel de l'objet pointé par ton pointeur d'implémentation te permet d'adapter ton comportement à ce qui doit être effectivement effectué.

Je comprends pas bien ce que tu entends par "changer le type réel de l'objet pointé par ton pointeur d'implémentation". Après je comprends le contexte, une interface implémentée par différents objets. Mais je ne vois pas bien ou se situe l'idiome pimple là-dedans. Je ne vois qu'une interface et donc du polymorphisme au niveau du passage par le pointeur de la l'objet de base.

Pourrais-tu développer d'avantage ?

Merci beaucoup!

[koala01]

Je comprends pas bien ce que tu entends par "changer le type réel de l'objet pointé par ton pointeur d'implémentation". Après je comprends le contexte, une interface implémentée par différents objets. Mais je ne vois pas bien ou se situe l'idiome pimple là-dedans. Je ne vois qu'une interface et donc du polymorphisme au niveau du passage par le pointeur de la l'objet de base.

Pourrais-tu développer d'avantage ?

Ben, justement, dans le fait que tu vas travailler, en interne, avec un pointeur sur l'interface, alors que ce pointeur pointera vers une instance d'un des types dérivés.

Reprenons l'exemple de l'affichage (text / OpenGl / DirectX).

L'interface pourrait ressembler à quelque chose comme

Code :

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

1
2
3
4
5
class Drawer{
    public:
        virtual ~Drawer();
        virtual void draw() = 0;
};

Pour l'affichage texte, la classe ressemblerait sans doute à quelque chose comme

Code :

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

1
2
3
4
5
6
7
8
class TextDrawer(){
    public:
        virtual void draw(){/* le comportement particulier pour l'affichage sous forme de texte */}
          /* quelques comportements spécifiques dont on a besoin */
          void subDraw1();
          void subDraw2();
          /* ...*/
};

De même, nous aurions les classes OpenGlDrawer et DirectXDrawer qui seraient composées de manière fort similaire.

Puis, j'ai une vue (qui est ce que je vais devoir manipuler). Cette vue disposer d'un pointeur sur Drawer pour pouvoir être affichée.

Elle va donc ressembler à quelque chose comme

Code :

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

1
2
3
4
5
6
7
class View{
    public:
        /* ...*/
        void draw(){drawer_->draw();}
    private:
        Drawer * drawer_;
};

Lorsque je vais instancier ma classe View, je vais devoir fournir (d'une manière ou d'une autre) un pointeur "passant pour être" de type Drawer à fin d'initialiser drawer_.

comme la classe Drawer n'est pas instanciable (du fait de la présence d'au moins une fonction virtuelle pure), je devrai en réalité passer un pointeur (de type Drawer ou dérivé) qui pointe sur l'un des types dérivé de Drawer, à savoir un objet dont le type réel est TextDrawer, OpenGlDrawer ou DirectXDrawer.

Mais la vue n'a absolument pas à s'inquiéter de connaitre ce type réel car, tout ce que la vue sait, c'est qu'il s'agit d'un objet dont l'interface correspond à Drawer.

Le principe de l'idiome du pointeur d'implémentation n'est rien d'autre que cela: Faisant simplement en sorte que le pointeur drawer_ pointe en réalité sur un objet de type différent (TextDrawer, OpenGlDrawer ou DirectXDrawer), il te permet d'adapter un comportement commun (Drawer::draw() ) à ce qui devra effectivement être effectué dans le contexte de l'utilisation de l'objet réellement pointé.

Enfin, au niveau du type réel (TextDrawer, OpenGlDrawer ou DirectXDrawer), étant donné que l'utilisateur n'aura jamais accès à ces types particuliers, il n'y a strictement aucun problème à ce que tout soit publique si cela facilite la tâche d'un système de génération automatique

Ce principe permet, au final, d'apporter un "point de variation" quelque part sans que cela n'implique de changements au reste de ton projet.

Qt utilise très régulièrement le principe du pointeur d'implémentation, dont, lorsqu'on travaille avec une interface générée par QtDesigner

[sfarc]

Le principe de l'idiome du pointeur d'implémentation n'est rien d'autre que cela: Faisant simplement en sorte que le pointeur drawer_ pointe en réalité sur un objet de type différent (TextDrawer, OpenGlDrawer ou DirectXDrawer), il te permet d'adapter un comportement commun (Drawer::draw() ) à ce qui devra effectivement être effectué dans le contexte de l'utilisation de l'objet réellement pointé.

Quand tu dis "n'est rien d'autre que cela", tu veux dire que cette logique correspond à l'une des applications possibles de l'idiome pimple qui, plus généralement, consiste tout simplement à utiliser un pointeur sur un objet "opaque" dont les changements n'affecteront pas le reste de l'application c'est bien ça ?

Par exemple avec QtDesigner et les interfaces, si j'ai une QMainWindow, tout changement de l'interface passant par le designer, c'est seulement le MainWindow_ui qui sera recompilé. Après ici, l'intérêt est limité non ? QMainWindow ne doit pas être utilisé à beaucoup d'endroits, donc pas beaucoup de gain de performance à la compilation notamment même si des changements via le designer peuvent être fréquents.

[koala01]

Quand tu dis "n'est rien d'autre que cela", tu veux dire que cette logique correspond à l'une des applications possibles de l'idiome pimple qui, plus généralement, consiste tout simplement à utiliser un pointeur sur un objet "opaque" dont les changements n'affecteront pas le reste de l'application c'est bien ça ?

Oui, c'est une manière d'envisager les choses

Par exemple avec QtDesigner et les interfaces, si j'ai une QMainWindow, tout changement de l'interface passant par le designer, c'est seulement le MainWindow_ui qui sera recompilé. Après ici, l'intérêt est limité non ? QMainWindow ne doit pas être utilisé à beaucoup d'endroits, donc pas beaucoup de gain de performance à la compilation notamment même si des changements via le designer peuvent être fréquents.

En effet.

Cependant, il y a un autre intérêt qui est, en définitive, surtout lié à la génération automatique de code.

En effet, si tu créais (tu peux d'ailleurs le faire ) ton interface graphique "a mano":

1. les différents "widgets" iraient dans l'accessibilité privée,
2. Certains slots seraient privés, d'autre publics
3. Certaines fonctions seraient publiques et d'autres privées

(1) serait facile à programmer, mais, comme "ui" est externe, il faudrait de toutes manières que ton interface puisse y accéder
(2) et (3) seraient beaucoup plus difficile à mettre en oeuvre : quelle fonction (ou quel slot) devrait être publique et quel(le) autre devrait être privé

Sans oublier, bien sur, qu'il faudrait toujours que ton interface puisse y accéder

Et le problème ne serait résolu ni en envisageant un héritage publique ni (encore moins) en envisageant un héritage privé

Le fait de passer par l'idiome du pointeur d'implémentation permet d'avoir une "politique" au niveau de ui beaucoup plus simple : tout est publique (de toutes manières, cela n'occasionne aucun problème en terme d'accessibilité), et le créateur de l'interface (toi ) décide, au "coup par coup" quelles fonctions et quels slots il place dans quelle accessibilité

[sfarc]

(1) serait facile à programmer, mais, comme "ui" est externe, il faudrait de toutes manières que ton interface puisse y accéder

Je ne comprends pas bien, pourquoi passer par ui quand on créé sa propre interface à la main ? On peut directement faire :

Code :

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

1
2
3
4
5
6
7
8
9
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
 
    FenPrincipale fenetre;
    fenetre.show();
 
    return app.exec();
}

Code :

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

1
2
3
4
5
6
7
8
class FenPrincipale : public QMainWindow
{
    public:
        FenPrincipale();
 
    private:
 // composants initialisés dans le cpp de FenPrincipale
};

Pour le reste, je comprends sinon, même si je ne pense pas utiliser le designer pour les slots (je ne veux pas mélanger la gestion des événements avec la génération de la vue).

[koala01]

Je voulais dire: en créant ta fenêtre à mano, tu peux assez facilement placer "n'importe quoi" dans "n'importe quelle accessibilité", et qu'on peut d'ailleurs parfaitement le faire de cette manière.

Avec un système de génération automatique, il est beaucoup plus difficile d'arriver à ce résultat, et, même si l'on pouvait arriver à programmer ce genre de choix pour la génération automatique, nous en reviendrions de toutes manières au problème que les éléments se trouvant dans la partie générée de manière automatique devraient être accessible depuis ta fenêtre

[sfarc]

Ok je vois

Merci encore koala01 pour tes explications

J'ai pu découvrir le pointeur d'implémentation ou pImpl, ou plutôt mettre un nom sur un idiome que j'utilisais déjà sans le savoir