Discussion :

[Bousk]

Tu confonds tout et cherches la petite bête dans mes propos...

Tu déclares toutes les méthodes que tu veux dans ta classe fille, mais tu n'es sensé manipuler que les méthodes de la classe mère si tu utilises un pointeur vers mere. Il est juste hors de question de faire un if ou quoi que ce soit pour dire "non mais mere là en fait c'est fille, alors j'apelle la méthode spécifique fille".
Si tu as besoin d'utiliser une méthode spécifique fille, tu travailles avec une fille.

Je ne vois pas en quoi ce que tu dis interdit de définir une nouvelle méthode sur la classe file.

Parce qu'encore une fois, tu veux comprendre ce que tu veux de mes propos.
Tu définis ce que tu veux pour ta classe fille, mais seules les méthodes virtuelles et héritées définissent l'interface de la mere, et donc de la fille. Les méthodes utilisent ce qu'elles veulent en interne à fille, y compris des méthodes propres à fille, mais c'est de l'implémentation interne.

Si tu étends l'interface de fille, ce n'est que de fille et non de mere. Donc soit tu manipules une fille, soit tu utilises l'interface de mere.

Disons que j'ai une classe mère Véhicule, qui a deux classes filles Voiture et Vélo.
En gros, tu m'interdis de créer le service démarrer() pour la classe Voiture, parce qu'elle n'est pas factorisable dans la classe Véhicule (on ne démarre pas un vélo).
Je suis supposer la pousser, ma voiture ?

Qui interdit d'avoir une méthode vehicule::demarrer ? A part toi personne ici.
Qui a dit qu'une méthode devait toujours faire qqch ? Qui interdit un vélo de démarrer et de ne rien faire sur une telle action ?
Par contre oui je t'interdis, puisque tu sembles apprécier ce terme, de faire un appel à demarer de voiture alors que tu manipules un vehicule qui ne détermine pas cette fonction.
Et plus fort que ça, ton compilateur te l'interdira tout bonnement.

Les classes fille peuvent redéfinir des méthodes, mais il s'agira de méthodes privées et qu'elles seules, et ceux qui travaillent avec elles en tant que telles (et non en tant que Mere mais en fait c'est une Fille), peuvent utiliser. Et certainement pas quelqu'un qui travaille avec une Mere.

Je suppose que tu chipottes pour le privé, qui est là pour distinguer de l'interface héritée de mere et non du mot-clé private.
Alors relis bien le reste de la phrase peut-être.

elles seules, et ceux qui travaillent avec elles en tant que telles (et non en tant que Mere mais en fait c'est une Fille), peuvent utiliser. Et certainement pas quelqu'un qui travaille avec une Mere

[oodini]

Tu confonds tout et cherches la petite bête dans mes propos...

C'est toi qui confond. Je répondais initialement à cette phrase de ton cru :

Si l'on doit réaliser un traitement différent, que l'on ne peut factoriser dans les services ou comportements de la classe, l'héritage est superflu et non avenu.

Tu déclares toutes les méthodes que tu veux dans ta classe fille, mais tu n'es sensé manipuler que les méthodes de la classe mère si tu utilises un pointeur vers mere.

C'est bien pour ça que j'avais précisé :

Ce sur quoi on peut s'interroger, c'est sur la pertinence de tout mettre dans un seul vecteur.

Si tu as besoin d'utiliser une méthode spécifique fille, tu travailles avec une fille.

Ben voilà. Exactement ce que je propose implicitement ci-dessus, par l'utilisation d'un second conteneur de classes filles ayant besoin du traitement spécifique.

Il est juste hors de question de faire un if ou quoi que ce soit pour dire "non mais mere là en fait c'est fille, alors j’appelle la méthode spécifique fille".

À aucun moment je n'ai encouragé cette manière de faire. J'ai à un moment évoqué dynamic_cast, mais en disant que ce n'était généralement pas une solution très heureuse.

Parce qu'encore une fois, tu veux comprendre ce que tu veux de mes propos.

J'ai l'impression inverse, désolé.
Interroge-toi sur la pertinence de ta première réponse à l'attention de mon auguste personne.

Tu définis ce que tu veux pour ta classe fille, mais seules les méthodes virtuelles et héritées définissent l'interface de la mere, et donc de la fille. Les méthodes utilisent ce qu'elles veulent en interne à fille, y compris des méthodes propres à fille, mais c'est de l'implémentation interne.

Si tu étends l'interface de fille, ce n'est que de fille et non de mere. Donc soit tu manipules une fille, soit tu utilises l'interface de mere.

Mais à quel moment ai-je tenu une position inverse ?

Qui interdit d'avoir une méthode vehicule::demarrer ?

Le bon sens.
Les classes filles doivent offrir une implémentation de l'interface décrite par la classe mère.
Or, un vélo, ça ne se démarre pas.

A part toi personne ici.

Apparemment, tu as déjà en main des sondages sur cette question.

Qui a dit qu'une méthode devait toujours faire qqch ? Qui interdit un vélo de démarrer et de ne rien faire sur une telle action ?

Mais bien sûr : quel constructeur va donc mettre sur un vélo un démarreur qui ne fait rien ?

Tu offres dans les services de vélo un service qui ne fait rien : tu mens.
Tu peux aussi mettre une fonction faireLePlein(), si tu veux.

Je suppose que tu chipottes pour le privé, qui est là pour distinguer de l'interface héritée de mere et non du mot-clé private.

Je n'en ai ni le besoin, ni l'envie.

Alors relis bien le reste de la phrase peut-être.

Relis bien ta première réponse à mon attention, et interroge-toi sur sa pertinence.

[koala01]

Qui interdit d'avoir une méthode vehicule::demarrer ? A part toi personne ici.
Qui a dit qu'une méthode devait toujours faire qqch ? Qui interdit un vélo de démarrer et de ne rien faire sur une telle action ?
Par contre oui je t'interdis, puisque tu sembles apprécier ce terme, de faire un appel à demarer de voiture alors que tu manipules un vehicule qui ne détermine pas cette fonction.
Et plus fort que ça, ton compilateur te l'interdira tout bonnement.

A vrai dire, rien dans le langage ne t'interdira de prévoir une fonction (quelle qu'elle soit et quoi qu'elle fasse... ou non) dans la classe mère, mais, en terme de conception, il y a surement matière à chicaner

Il faut se rappeler que la décision de déclarer et de définir une fonction membre est une décision conceptuelle, car on estime que cette fonction fait partie des services que l'on est en droit (ou que l'on croit être en droit ) d'attendre de la part de la classe que l'on crée, et qu'aucun langage ne sera jamais armé pour juger de l'opportunité d'un choix de conception

Par contre, ce qui t'interdira normalement de déclarer une fonction virtuelle pure "demarrer" dans une classe Véhicule, c'est le LSP

En effet, LSP t'impose que toute propriété valide pour la classe de base soit également valide pour la classe dérivée.

En ce sens, si tu déclares une fonction "demarrer" dans la classe véhicule, il faut que cette fonction ait un sen pour toutes les classes qui héritent (ou qui hériteront) de véhicule.

Si on estime (et je fais partie de ceux qui l'estiment ) qu'il n'y a aucun sens à avoir une fonction démarrer pour un vélo alors qu'elle existe au niveau de la classe Véhicule, nous nous trouvons avec une propriété valide pour la classe Véhicule qui est invalide pour la classe Vélo, et donc, l'héritage est conceptuellement interdit au termes de LSP.

Si tu retires cette fonction de l'interface de Véhicule et que tu ne garde que, dans Véhicule, que des fonctions qui ont un sens quel que soit le type réel de véhicule envisagé (aussi bien la voiture, le vélo que les patins à roulettes ), alors tu te trouves dans une situation dans laquelle LSP est respecté, et l'héritage admis .

Mais cela nous ramène de plein pied au problème d'origine: cette fonction démarrer ne se retrouvera que dans l'interface de certaines classes dérivées de Véhicule, et il s'agira donc d'accéder aux instances de ces classes sous la forme d'un pointeur (ou d'une référence) sur leur type réel.

Et comme tu as raison de dire qu'il ne faut à aucun prix accepter une logique de transtypage (quel que puisse être la manière dont il est envisagé), il s'agit de mettre en place d'autres solutions:

• Soit en maintenant séparément des listes des différents types de véhicules que l'on manipule
• Soit en recourant au double dispatch