Polymorphisme statique et dynamique

Hello,

Le polymorphisme dynamique (virtual) est plus gourmand que le polymorphisme statique (CRTP).
Mais il est également plus lisible.

Ma question est donc : quand le polymorphisme statique (CRTP) est suffisant, l'utilisez-vous systématiquement ?
Ou seulement après profiling (théorique ou pratique) ?

A mes yeux, ils n'ont surtout pas du tout le même rôle.

Le crtp est là pour faciliter le partage de code, en conservant une grande précision de typage.
Le virtual permet au contraire de manipuler ensemble et de la même manière des références vers des types distincts mais liés (cousinage)

Ils n'interviennent pas au même moment.
J'aurai tendance à faire intervenir le crtp par un héritage privé ou protégé.

Citation:

---

Envoyé par leternel

A mes yeux, ils n'ont surtout pas du tout le même rôle.

---

Je connais bien les cas d'utilisation de chacun, leurs avantages et leurs inconvénients.

Mais avant que chacun d'entre nous ne découvre le CRTP, nous avons tous utilisé du polymorphisme dynamique là où du statique aurait mieux convenu.
Et force est de reconnaître que je tombe souvent sur du code fonctionnant sur ce mode, et que je me pose alors la question : dois-je refactorer ?

Enfin, le code CRTP est moins lisible (on repère moins facilement la notion de virtualité), et donc je me posais la question.

Pour ta question de lisibilité: mais justement, on ne veut pas proposer de virtualité dans le CRTP.

Pour la question du réfactor: "ça dépend"

Ca dépend de si tu y es autorisé.
Ca dépend aussi de l'avantage que l'application y gagne.
Le premier problème de la reconstruction, c'est le risque de régression.

Si tu peux diviser par deux la taille du code, à fonctionnalité égale, et sans passer par des siouxeries, c'est probablement une bonne idée.
Si tu peux réduire la taille du code utilisateur, quitte a grossir un peu le code interne, pourquoi pas.

Si tu améliore la maintenabilité en augmentant la clarté, je t'encourage à militer pour ce changement, voire à le faire dans ton coin, et montrer après que c'est clairement mieux.

Si ca ne change rien: même code d'appel, performance similaire et, surtout, même maintenabilité, ne le fait pas.

Citation:

---

Envoyé par leternel

Pour ta question de lisibilité: mais justement, on ne veut pas proposer de virtualité dans le CRTP.

---

Je voulais dire que le mot-clé virtual permettait de rendre visible la redéfinition.

Je suis assez d'accord sur le reste.

Autre sujet : parfois, on ne sait pas toujours à l'avance si le polymorphisme aura besoin d'être un jour dynamique.
Le CRTP peut s'imposer d'évidence quand l'architecture est stabilisée. D'ici là : statique (blindé) ou dynamique (simple à lire et coder) ?

Je pense que ça dépend de l'usage prévisible.

Si une variable polymorphique spécifique est amenée à contenir plusieurs valeurs de types différents, le dynamique est de rigueur.
Si cette variable ne reçoit que des valeurs du même type, c'est du template/CRTP.

Et je considère la variable au sens de champ d'une instance spécifique de la classe à coder.

Salut,

D'abord, il faut savoir que le polymorphisme par CRTP n'est qu'une possibilité offerte par le paradigme générique alors que le polymorphisme "classique" (qui est en réalité le polymorphisme par inclusion ;)) est une possibilité du paradigme orienté objet. Autre paradigme, autres moeurs ;-)

D'une certaine manière, nous pourrions dire que le CRTP permet d'adapter un comportement déterminé à un grand nombre de types différents, alors que polymorphisme d'inclusion permet, au contraire d'obtenir plusieurs comportements "cohérents" pour tout objet qui pourrait être connu comme étant de type identique (ou à défaut compatible).

Je m'explique:
Si tu as une classe utilisée pour le CRTP ressemblant à

Code:

---

1 2 3 4 5 6 7 8

template <typename T> class MyClass{ public: void foo(){ /* ... */} protected: MyClass(); ~MyClass(); };

---

tu as la certitude que le comportement sera toujours identique, clairement défini, quel que soit le type réel de T, alors que, en programmation orientée objet, on va plutôt partir du principe qu'une classe de base (Forme) expose un service donné (Draw) qui devra s'adapter au type réel de la donnée maniupulée

Code:

---

1 2 3 4 5 6 7 8 9

int main(){ Forme * circle= new Circle(/* ... */); Forme * rectangle= new(/* ... */); circle->draw(); // "I am a circle" rectangle->draw(); // "I am a rectangle" delete circle; delete rectangle; return 0; }

---

L'énorme avantage du CRTP est qu'il te permet surtout de respecter un des principes de base : Don't Repeat Yourself, en passant par un respect plus stricte d'ISP (principe de ségrégation des interfaces).

Maintenant que l'on est sur de partir sur une base saine et commune, la question qui fâche : faut il, oui ou non, décider de refactoriser systématiquement tous les projets qui utilisent le paradigme OO alors que le paradigme générique et le CRTP semblent plus intéressants :question:

Je crois personnellement que la réponse varie entre "oui sauf" et "non, à moins que"... Mais là encore, cela mérite sans doute une explication supplémentaire :D

Je dirais que, de toutes façons, ce genre de refactorisation ne doit se faire qu'à l'occasion d'un passage de version majeure, essentiellement pour éviter de briser la compatibilité binaire à l'occasion d'un "bugfix".

Une fois qu'il est bien établi que cette refactorisation ne doit pas intervenir à tords et à travers, il faut réfléchir à quand elle s'avère utile, intéressante ou nécessaire et quand elle s'avère au contraire totalement inutile.

Déjà, si les principes OO (LSP en tête) sont parfaitement respectés avec l'approche OO de ton code, je crois que la refactorisation du projet n'aura aucun intérêt autre que purement intellectuel. Autrement dit: fait le si tu as le temps et que tu t'ennuies, mais gardes toujours bien une version fonctionnelle utilisant le paradigme OO... Jusqu'à ce que tu sois en mesure de fournir un version entièrement refactorisée.

Par contre, si tu te rend réellement compte que l'approche OO ne respecte pas les principes de base de ce paradigme (LSP en tête), il est sans doute très intéressant d'envisager la refactorisation, en gardant en tête que cela risque très certainement d'avoir des conséquences "incontrôlées" dans le sens où la refactorisation a de bonne chances de casser beaucoup plus de code que ce que tu n'aurais pu l'imaginer au départ.

Et puis, bien sûr, il y a tous les cas qui peuvent prendre place entre les deux, où les principes du paradigme OO sont "dans l'ensemble bien respectés", mais où l'on se rend compte que le DRY est très loin de l'être. Pour tous ces cas "entre deux" (et pour tous les autres, d'ailleurs :P), je crois que la décision doit être prise "au cas par cas" ;)

Mais garde toujours en tête le fait qu'une refactorisation, quelle qu'elle soit, prend souvent beaucoup plus de temps que l'on n'aurait pu l'imaginé au début. Généralement, on se dit que "bah, en deux heures c'est emballé", et on se retrouve, trois jours plus tard, avec quelque chose qui ne compile toujours pas :aie: Il arrive parfois que l'on soit surpris à l'inverse, que l'on prévoie trois jour de travail pour se rendre compte qu'il suffit de changer deux lignes de code afin d'apporter l'amélioration souhaitée... Mais c'est quand même beaucoup, beaucoup, beaucoup plus rare ;)