Discussion :

[Alp]

Je n'ai utilisé ce pronom que par facilité, parce que c'est l'argumentation que je tiendrais vis à vis de quiconque essayerais de me convaincre

Je sais, mais je fais partie des personnes auxquelles tu t'adresses, et j'ai justement dit plus haut :

Penses-tu vraiment que je (ou quelqu'un qui fait pareil) m'encombrerais avec ce genre de détails si c'était fait de manière arbitraire ?
De manière générale, ne sous-estime pas les personnes qui se soucient de ce genre de détail, on n'est plus au niveau de leur rappeler que la classe ou son éco-système est susceptible d'évoluer et doit être ainsi être aussi facile que possible à maintenir...

Ensuite, je ne suis pas en train d'essayer de convaincre qui que ce soit. J'expose une pratique dans "la place publique", afin que des personnes que ça intéresse puissent l'utiliser.

[oxyde356]

Je pense qu'en effet pour une question de lisibilité il est bien mieux de mettre le virtual dans chaque classe fille plutôt que juste dans celle qui sont susceptibles de l'implémenter, moi je fais du travail collaboratif là et j'ai plutôt intérêt de le mettre partout pour mes coéquipier sinon il serait fort possible qu'ils soient perdus dans mes classes Hors ce que l'on fait parce que l'on travaille à plusieurs on est censé le faire tout le temps ^^

[Zenol]

Je pense qu'en effet pour une question de lisibilité il est bien mieux de mettre le virtual dans chaque classe fille plutôt que juste dans celle qui sont susceptibles de l'implémenter, moi je fais du travail collaboratif là et j'ai plutôt intérêt de le mettre partout pour mes coéquipier sinon il serait fort possible qu'ils soient perdus dans mes classes Hors ce que l'on fait parce que l'on travaille à plusieurs on est censé le faire tout le temps ^^

Toute fois, Alp précise ne "masquer" le virtual uniquement pour les méthodes pour les quels on ne devrais pas avoir à hériter.

Donc, logiquement, quelqu'un qui se contente de lire la déclaration de la classe fille ne devrais pas avoir besoin de penser à redéfinir ces fonctions.
Si vraiment il souhaite le faire, connaitre cette possibilités l'oblige à justement bien avoir conscience de la hiérarchie et d'une certaine façon, peut-être qu'en découvrant que ces méthodes sont virtuel, il découvriras qu'il fait fausse route et possède une méthode bien plus élégante de parvenir à ses fins.

[koala01]

Si vraiment il souhaite le faire, connaitre cette possibilités l'oblige à justement bien avoir conscience de la hiérarchie

Il y a, à mon sens, une différence entre le besoin d'avoir une bonne conscience des différentes relation EST UN de la hiérarchie qui ont mené à l'existence d'une classe fille et le fait de rendre quasi obligatoire le fait de parcourir cette hiérarchie afin de s'assurer de l'éventuelle virtualité d'une fonction

d'une certaine façon, peut-être qu'en découvrant que ces méthodes sont virtuel, il découvriras qu'il fait fausse route et possède une méthode bien plus élégante de parvenir à ses fins.

Ce n'est pas faux, mais, à mon sens, on a beaucoup plus vite fait d'oublier si telle ou telle fonction est virtuelle ou non que d'oublier que, parce qu'une classe hérite d'une autre, elle présente une interface donnée... d'autant plus que l'intellisens est souvent là pour nous rappeler les interfaces héritées

Du coups, j'aurais tendance à dire que cet argument est, certes valable, mais qu'il ne l'est qu'en période "d'apprentissage" des possibilités de la bibliothèque / hiérarchie de classes

[Alp]

Bon je vais approfondir un peu plus pour en fait étayer ce que Zenol a dit, et qui va dans mon sens.

Quand vous définissez une classe, qui n'a rien de spécial, sauf déclarer des fonctions virtuelles (éventuellement pures). Chacune de ces fonctions virtuelles représente un comportement personnalisable qui est +- orthogonal à celui des autres. Par exemple, une classe de base d'un framework de GUI définira une classe Widget, qui aura des fonctions virtuelles pour ce qui se rapporte 1/ au dessin 2/ à la réaction face au clic 3/ à la réaction face à l'appui d'une touche sur le clavier [...].

Bon, maintenant, on va sous-classer Widget pour définir une classe de zone de texte mais abstraite (car elle va définir certaines fonctions virtuelles, qui fixeront le comportement face à un certain nombre de choses : elle va contenir du texte et fournira des primitives pour en faire le rendu, elle permettra de le sélectionner etc, mais elle n'aura aucune réaction face à l'appui de touche sur le clavier par exemple, car ça peut être un simple label, une zone de texte d'une ligne ou une zone de texte multiligne). Ensuite, on va sous-classer notre classe abstraite de zone de texte en 1) Label 2) SingleLineEdit 3) MultiLineEdit. Label n'aura aucune réaction face à un évènement clavier par défaut, et à l'affichage elle ne dessinera pas de fond blanc, etc. Bon je vais pas tout décrire, vous savez à quoi ressemble tout ça.

L'idée clé ici est que à partir de ma classe de zone de texte abstraite, j'ai fixé certaines parties du comportement d'un widget qui vont être propres à toute la hiérarchie des zones de texte, i.e toutes les classes qui seront descendantes de notre zone de texte abstraite. Evidemment, on pourra le redéfinir, mais c'est un exemple typique où je ne mettrai pas virtual (même si la fonction l'est) parce que sauf cas exceptionnel je n'aurai pas à redéfinir l'une des choses qui caractérise cette partie de l'arbre d'héritage.

Après, ça ne change effectivement rien, et comme je l'ai dit c'est juste une convention que j'adopte parfois, selon le contexte. C'était juste pour illustrer un peu mieux ce que je voulais dire dans mes posts précédents.

[Lavock]

En gros, tu ne met pas le mot virtual lorsque le comportement se rapproche de "final".

Je pense pas que koala te reproche de mettre un final like, mais la façon dont tu le fais.
J'ai l'impression qu'il aurait plus tendance à faire quelque chose comme :

Code :

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

1
2
 
/* final */ virtual func();

J'ai mal compris ?

[Alp]

En gros, tu ne met pas le mot virtual lorsque le comportement se rapproche de "final".

Je pense pas que koala te reproche de mettre un final like, mais la façon dont tu le fais.
J'ai l'impression qu'il aurait plus tendance à faire quelque chose comme :

Code :

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

1
2
 
/* final */ virtual func();

J'ai mal compris ?

C'est l'idée oui, je pense.

[3DArchi]

C'est l'idée oui, je pense.

J'ai quand même du mal avec cette idée de final.
Quand ta classe intermédiaire propose une spécialisation pour une fonction virtuelle pure d'une classe de base, c'est déjà une indication qu'un comportement existe. Mais, vouloir dire qu'il s'agit d'un comportement figé, là j'ai plus de mal.
Même si je comprend ce que tu veux faire, je reste persuadé qu'il s'agit d'une mauvaise idée au regard de la lisibilité du code, et notamment par quelqu'un qui serait nouveau dans le projet et qui n'aurait pas ton talent. Il y avait un ou deux articles là dessus dans dr dobbs. Faudra que je prenne le temps de les retrouver.

[Alp]

Oui oui, mais comme je l'ai dit, je ne l'applique pas toujours, cela dépend du contexte.

[koala01]

Sincèrement, je comprend le point de vue, mais je ne suis pas d'accord avec lui, et non, ce n'est pas la manière de faire un "final like" que je reproche.

Ce que je reproche au fait de surprimer le mot clé virtual quand il n'est plus indispensable c'est que tu perd une information à la lecture du code.

D'un coté, pour les fonctions dont le comportement peut encore être redéfini, tu perd la capacité à repérer "facilement" les fonctions susceptibles d'être redéfinies, et de l'autre (pour les fonction redéfinies avec un comportement plus ou moins définitif, ou pouvant être considéré comme tel), tu perd la capacité de te rendre compte que c'est, justement, l'adaptation du comportement d'une partie de l'interface héritée.

Comme tu perd quelque chose dans les deux cas, et que tu n'a pas grand chose à gagner par ailleurs (à part les quelques secondes économisées en n'écrivant pas le mot clé virtual), je ne vois aucun avantage à agir de la sorte.

Quand on y pense, le mot clé virtual prend, à la lecture du code, deux significations particulière:

• dans les classes dérivée, il prend la signification de "je modifie le comportement défini dans la classe mère"
• dans les classe de base, il prend la signification de "le comportement de cette fonction est susceptible d'être redéfini"

Avec une classe dérivée proche de

Code :

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

1
2
3
4
5
class Derived : public Base
{
    public:
        virtual void doSomething();
};

tu peux donc analyser le code sous deux angles:

Soit tu analyse le code en prenant en compte le fait que Derived dérive de base (tu t'intéresse ici aux capacité de Derived)

Tu te rend compte que doSomething() a un comportement qui peut être considéré comme final (comprend: qui n'a plus lieu d'être redéfini si on hérite de Derived), mais il s'agit d'un rappel du fait que doSomething() fait partie de... l'interface publique de Base.

Soit tu te palce du coté de la création d'une classe dérivée de Derived, et tu t'apprete donc à écrire un code proche de

Code :

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

1
2
3
4
class D2: public Derived
{
    /*...*/
};

Et tu as, encore, deux solutions:

Soit le comportement de Derived::doSomething() te convient ou n'a pas lieu d'être redéfini, et tu ne déclarera plus doSomething() dans l'interface de D2 (que voudrais tu implémenter comme comportement à part Derived::doSomething() )

Soit tu es face à une situation dans laquelle tu souhaite redéfinir le comportement de doSomething et où la boucle sera bouclée...

Et, dans cette situation, le fait que le comportement soit hérité de Base ou non (car doSomething peut très bien être un ajout à l'interface) n'aura, en définitive, que peu d'importance, que ce soit pour toi ou pour le lecteur du code de la classe D2

[Lavock]

Je suis quand même d'avis qu'on bouge les posts relatif dans un nouveau file "L'intérêt de final en c++".

[Alp]

koala01, je comprends *parfaitement* ton point de vue, idem que pour 3DArchi. Et selon le contexte, c'est cette convention que j'utilise.

Celle que j'expose a toutefois fait ses preuves dans d'autres contextes. Cela dépend principalement de la nature de ce que j'écris (bibliothèque ou appli) et des gens avec qui je l'écris.

[3DArchi]

des gens avec qui je l'écris.

C'est là que je ne te suis pas. Tu ne sais pas à l'avance qui va reprendre ton code. Pour moi, toutes ces règles, c'est un peu comme la priorité des opérateurs. Tu peux écrire une expression sans parenthèses parce que tu maîtrises sur le bout des doigts les différentes priorités. Mais, c'est déjà une mauvais idée au regard de la maintenance du code (car un jour ou l'autre, il risque de passer dans des mains moins expertes). Mais aussi et surtout au regard de la lisibilité. Après, chacun ses pratiques. On est 'open-mind'

[Alp]

C'est là que je ne te suis pas. Tu ne sais pas à l'avance qui va reprendre ton code. Pour moi, toutes ces règles, c'est un peu comme la priorité des opérateurs. Tu peux écrire une expression sans parenthèses parce que tu maîtrises sur le bout des doigts les différentes priorités. Mais, c'est déjà une mauvais idée au regard de la maintenance du code (car un jour ou l'autre, il risque de passer dans des mains moins expertes). Mais aussi et surtout au regard de la lisibilité. Après, chacun ses pratiques. On est 'open-mind'

+1 sur toute la ligne. Je ne me permettrai jamais d'introduire ce genre de subtilités dans du code de bibliothèque open-source par exemple. Mais je l'avais par exemple mis en oeuvre dans un compilo "proof-of-concept", ou des autres projets d'applis. Mais dans un projet où il est probable que je ne sois plus dessus quelques temps après, et où le fait de préciser cette subtilité dans les style guidelines ne suffit pas pour certains des membres de l'équipe de dev, je ne me permerttrai jamais. L'idée maitresse reste quand même que les gens comprennent le plus rapidement possible un maximum sur ma classe en regardant son code ou sa doc. D'où le "ça dépend des gens". Et comme je le disais, je n'introduirai pas ça dans une bibliothèque par exemple, qui est, par sa nature, susceptible de passer entre n'importe quelles mains (au moins pour l'utilisation).

[koala01]

+1 sur toute la ligne. Je ne me permettrai jamais d'introduire ce genre de subtilités dans du code de bibliothèque open-source par exemple. Mais je l'avais par exemple mis en oeuvre dans un compilo "proof-of-concept", ou des autres projets d'applis. Mais dans un projet où il est probable que je ne sois plus dessus quelques temps après, et où le fait de préciser cette subtilité dans les style guidelines ne suffit pas pour certains des membres de l'équipe de dev, je ne me permerttrai jamais. L'idée maitresse reste quand même que les gens comprennent le plus rapidement possible un maximum sur ma classe en regardant son code ou sa doc. D'où le "ça dépend des gens". Et comme je le disais, je n'introduirai pas ça dans une bibliothèque par exemple, qui est, par sa nature, susceptible de passer entre n'importe quelles mains (au moins pour l'utilisation).

Quelque part, tu admets que les cas où tu te permettrait une telle pratique sont très limités...

Dés lors, pourquoi garder ces quelques cas "particuliers", étant donné qu'il (semble) admi que cela n'apporte pas grand chose :p

[Alp]

Quelque part, tu admets que les cas où tu te permettrait une telle pratique sont très limités...

Dés lors, pourquoi garder ces quelques cas "particuliers", étant donné qu'il (semble) admi que cela n'apporte pas grand chose :p

Parce que je choisis la solution la plus efficace pour chaque situation Et, ces cas ne sont pas non plus *si limités que ça* dans mon quotidien.

[3DArchi]

Dés lors, pourquoi garder ces quelques cas "particuliers", étant donné qu'il (semble) admi que cela n'apporte pas grand chose :p

Licence poétique