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