Discussion :

[gbdivers]

Bonjour à tous

A priori, j'ai l'impression que l'idome Pimpl présente que des avantages et aucun défaut (juste une indirection supplémentaire). Cet idome est utilisé dans la majorité des classes de Qt. Les avantages sont :
- de faciliter la compatibilité binaire. Voir Pensées sur la compatibilité binaire de Thiago Macieira ;
- d'améliorer la stabilité de l'interface publique (en permettant de pouvoir changer la partie private de la classe sans avoir à recompiler l'ensemble des dépendances). Voir Guru of the Week #100 et Guru of the Week #101 de Sutter ;
- de diminuer les temps de compilation (en minimisant les dépendances dans les fichiers d'en-tête).

Donc, quand faut-il utiliser Pimpl ? Ou plus précieusement, quand ne pas l'utiliser et pourquoi ?

[screetch]

pour moi il y a pas mal de travail supplémentaire en utilisant pimpl; le principal etant de "forwarding" de l'interface publique; un autre la complexité de faire des appels virtuels sans causer de bugs.

Or on m'a toujours dit de coder des petites classes; mes classes font rarement plus de quelques lignes (dans le header) et environ 100 a 200 lignes dans le source; utiliser pimpl pour tous ces cas doublerait mon nombre de ligne pour être franc.

J'ai parfois l'impression que pimpl est souvent utiliser pour cacher la complexité d'une implémentation, en tous cas dans le monde pro quand je l'ai vu utiliser c'était souvent sur une classe avec une interface publique de 15 ou 20 methodes, donc tout de suite une grosse tuyauterie. Ca me donne surement un a priori negatif bien sur.

[koala01]

Salut,

Je t'avouerai que j'ai une très mauvaise expérience professionnelle du pimp parce que, dans mon travail actuel on l'utilise pour une classe pour laquelle la justification à son utilisation ne m'a pas vraiment convaincu (mais bon, je suis un "pisseur de code" sur ce projet ) et qu'il est mis en oeuvre pour un property manager qui a le très mauvais gout de reprendre toutes les propriétés (ayant trait à des domaines divers et variés) du projet.

Ceci dit, l'idiome peut avoir d'énormes avantages, mais à la condition expresse de... veiller à respecter malgré tout les autres règles (dont, essentiellement, la responsabilité unique).

Pour moi, pimp est à prendre comme toutes les autres techniques de programmation : très intéressantes si elles sont utilisées à bon escient, calamiteuses si elles le sont en dépit du bon sens...

Mais le gros du débat risque donc de dévier vers "quand pimpl est il utilisé à bon escient"

[Klaim]

Personnellement, le seul cas ou je vois un interet c'est quand on fournis une bibliothèque dont on ne peut fournir le code et qui doit avoir une interface compatible entre les versions des binaires. Du coup on doit fournir des headers bien précis qui cachent complètement ce qui se passe derrière ET qui n'utilisent pas de templates (qui posent problème quand on compile avec un compilateur différent de celui du binaire de la bibliothèque).

Au delà de ce cas bien précis, ça deviens vite beaucoup de travail pour pas grand chose.

D'ailleurs, beaucoup de bibliothèques "utiles" (qui n'implémentent pas un "système stable" comme DirectX ou autres) ne garantissent pas une compatibilitié de binaire et fournissent complètement leur code entre autre parcequeça évite d'avoir a faire ce genre de chose.


Au fait c'est pas plutot PIMPL ? Pointer Implementation ...

[gbdivers]

Au fait c'est pas plutot PIMPL ? Pointer Implementation ...

Erreur de frappe dans le titre. Corrigé


Ok. Donc si je résume :

- de faciliter la compatibilité binaire

Peu utile, sauf pour certaine bilbiothèque

- d'améliorer la stabilité de l'interface publique
- de diminuer les temps de compilation

Détails par rapport à la perte de temps de dev que cela implique

Je l'utilise pas non plus en général. Je me posais la question de savoir si je n'utilisais cette approche, qui n'aurait que des avantages, que par habitude de vieux codeur et non par choix technique.

[ptyxs]

Par parenthèses sur pimpl :
http://herbsutter.com/gotw/_100/
http://herbsutter.com/gotw/_101/

[gbdivers]

Par parenthèses sur pimpl :
http://herbsutter.com/gotw/_100/
http://herbsutter.com/gotw/_101/

Ce sont les articles que j´ai cité dans mon premier post et qui m´ont interpelé sur cette question

[oodini]

Pour moi, c'est utile quand tu dois fournir une API, et que tu dois assurer une relative stabilité de l'interface.

[koala01]

Pour moi, c'est utile quand tu dois fournir une API, et que tu dois assurer une relative stabilité de l'interface.

Le seul respect de l'OCP devrait déjà te fournir la stabilité requise

Non, je verrais plutot son utilité dans le cadre d'un DP bridge ou façade

Mais, encore faut-il que cette façade ou ce pont soient, effectivement nécessaires

Si l'on s'amuse à faire un pont ou une façade uniquement "parce que l'on risque de vouloir changer" (de SGBDR ou de bibliothèque IHM) alors qu'on sait très bien que ce ne sera jamais le cas, ne se fait on pas du mal juste pour le plaisir

[therwald]

- d'améliorer la stabilité de l'interface publique (en permettant de pouvoir changer la partie private de la classe sans avoir à recompiler l'ensemble des dépendances).

Pour avoir ça, ne peut-on pas se contenter de coder par interface dans les classes pour lesquelles c'est critique (pour moi, surtout les points d'entrée d'API)?
Si on définit une interface avec seulement les méthodes publiques virtuelles pures et qu'on met leur vraie implémentation (et les membres/méthodes privées) dans une dérivée, est-ce qu'on n'arrive pas plus simplement à ce résultat?

[JolyLoic]

Ça dépend ce qu'on entend par interface. On peut entendre par là le concept (séparation de l'implémentation) où la traduction du mot clef utilisé dans d'autres langages (classe de base avec uniquement des fonctions virtuelles pures).

L'idiome pimpl est une façon de réaliser une interface (le concept) propre séparée de l'implémentation. Ce n'est pas la seule, l'interface (la traduction) est une autre façon de réaliser une interface (le concept).

Comme il y a plusieurs solutions, il faut proposer des critères de choix.

Pour des types à sémantique de valeur, j'ai tendance à largement préférer le pimpl : Le résultat est lui même à sémantique de valeur, on peut aisément le copier, l'assigner à une nouvelle variable, toutes choses difficiles/impossibles avec une classe de base que l'on doit manipuler par pointeur.

Pour des types à sémantique d'entité, que l'on doit de toute manière manipuler par pointeurs, je partirais peut-être plus vers la classe de base. Ne serait-ce que pour la possibilité d'implémenter plusieurs interfaces par un seul type. A noter que même dans ce cas, ma classe de base serait probablement plus riche qu'une interface au sens Java/C#, elle contiendrait par exemple des fonctions statiques servant de factory pour mon type.