Kevin Kofler (./1173) :
C'est surtout que je trouve ça crade. L'icône Ouvrir d'une application est une icône, pas une "icône ouvrir, sous-classe de icône". Question performances, ça ne change pas grand chose. Ça risque juste de prendre de la place dans l'exécutable (table de symboles etc.). Mon objection est liée à la conception, pas à la performance.

C'est un très bon modèle de conception, au contraire… Peut-être un des meilleurs…
Le nom choisi par Folco n'est certes pas idéal. Typiquement, on appellerait ça une commande. (Ouais, c'est un modèle de commandes quoi ^^)
Tu as une commande, avec un nom, un icône, une description, et une action qui est éxécutée.
Tu peux associer ta commande à un bouton de barre d'outils, un menu, un bouton standard, bref n'importe quoi. Les éléments prennent automatiquement le nom et l'icône associés à la commande, et lorsque tu active ces élément, la commande est éxécutée.
C'est le modèle le plus flexible qu'il est possible de concevoir (à ma connaissance), et il te permet d'avoir une interface utilisateur flexible et évolutive, avec un code propre et clair (contrairement au fouillis que tu as en général, avec les trucs genre un contrôle = une méthode ou bien les trucs crades tels que listeners et assimilés)

Donc la pénalité que tu te tapes, ce sont 2 lectures de pointeurs en mémoire (le pointeur sur la vtable et l'entrée dans la vtable) par appel de fonction virtuelle, mais ça s'arrête là.

MAIS ce double déréférencement est atroce au niveau des performances.