Discussion :

[Jcpan]

Bonjour

tout est dans le titre

Merci

[Linkin]

Le inherited seul est suffisant quand les paramètres de la fonction de la classe actuelle sont identiques à celles de la classe parente.

[Just-Soft]

Salut;

tout est dans la citation tirée de l'aide Delphi 7 :

Le mot réservé inherited joue un rôle particulier dans l'implémentation de comportements polymorphiques. Il peut apparaître dans une définition de méthode avec ou sans identificateur à la suite.

Si inherited est suivi par du nom d'un membre, il représente un appel de méthode normal ou une référence à une propriété ou à un champ, sauf que la recherche du membre référencé commence dans l'ancêtre immédiat de la classe de la méthode. Ainsi, quand l'instruction :

inherited Create(...);

se produit dans la définition d'une méthode, elle appelle la méthode Create héritée.

Quand inherited est utilisé sans être suivi d'un identificateur, il désigne la méthode héritée portant le même nom que la méthode en cours ou, si la méthode en cours est un gestionnaire de message, le gestionnaire de messages hérité pour le même message. Dans ce cas, inherited ne prend pas de paramètre explicite, mais transmet à la méthode héritée les paramètres utilisés pour l'appel de la méthode en cours. Par exemple*:

inherited;

apparaît fréquemment dans l'implémentation des constructeurs. Cette instruction appelle le constructeur hérité en lui transmettant les mêmes paramètres que ceux transmis au descendant.

Bonne chance.

[sjrd]

Et pour donner des recommandations directes, moi j'utilise inherited tout court quand je suis dans une méthode override ou message, et l'autre version dans tous les autres cas.

[Andnotor]

Un commentaire supplémentaire sur les fonctions:

Le nom de la fonction est obligatoire (avec paramètres s'il y en a) si le résultat doit être récupéré. Même s'il s'agit uniquement d'un override.

Code :

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

1
2
3
4
5
6
7
function TMaClass.MaFunction :boolean;
begin
  Result := inherited MaFunction;
 
  if Result then
    Result := ...  //Tests supplémentaires
end;

[peter27x]

Un commentaire supplémentaire sur les fonctions:

Le nom de la fonction est obligatoire (avec paramètres s'il y en a) si le résultat doit être récupéré. Même s'il s'agit uniquement d'un override.

Code :

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

1
2
3
4
5
6
7
function TMaClass.MaFunction :boolean;
begin
  Result := inherited MaFunction;
 
  if Result then
    Result := ...  //Tests supplémentaires
end;

Mais alors, question, est ce que mettre override dans la déclaration puis pas mettre inherited dans l'implémentation revient au même que pas mettre override dans la declaration mais mettre inherited dans l'impémentation ?

Oups, je crois que ma question est stupide, je la laisse malgré tout, sait on jamais le flot de connaissances qu'elle pourra m'apporter !

[Aka Guymelef]

Pas du tout, si tu met override dans la déclaration mais pas d'appel à l'inherited alors la méthode n'exécuteras que son contenu mais ne fera pas appels aux traitements hérités.

Par contre si tu ne met pas l'override mais fait un appel à l'inherited alors tu exécute les traitements de la méthode plus les traitements hérités. Sauf que dans l'opération tu as perdu la virtualité de ta méthode, ce qui t'oblige notamment à devoir utiliser inherited MaMethode + paramètres au lieu de juste inherited.
Tu devrais aussi recevoir un avertissement du compilateur qui t'indique que ta nouvelle méthode cache la méthode héritée.

[peter27x]

Pas du tout, si tu met override dans la déclaration mais pas d'appel à l'inherited alors la méthode n'exécuteras que son contenu mais ne fera pas appels aux traitements hérités.

Par contre si tu ne met pas l'override mais fait un appel à l'inherited alors tu exécute les traitements de la méthode plus les traitements hérités. Sauf que dans l'opération tu as perdu la virtualité de ta méthode, ce qui t'oblige notamment à devoir utiliser inherited MaMethode + paramètres au lieu de juste inherited.
Tu devrais aussi recevoir un avertissement du compilateur qui t'indique que ta nouvelle méthode cache la méthode héritée.

Override sert donc surtout à récupérer le nom d'une methode virtuelle de la classe mère ?

Tiens, d'ailleurs, quelle est la différence fondamentale entre virtual et abstract dans la def d'une méthode ? J'ai vu qu'on pouvait d'ailleurs mettre les deux.

[Aka Guymelef]

Override sert surtout à dire que je "redéfinie" le traitement hérité sans pour autant briser la virtualité de la méthode dans la classe de base.

Par définition une méthode abstraite (abstract) est virtuelle (virtual). Une méthode abstraite définit un prototype de méthode mais qui devra être redéfinit dans les classes hérités (donc pas d'implémentation dans la classe de base).

Néanmoins ça c'est la base de chez base du concept d'héritage des classes, à mon avis tu ferais mieux de chercher un bon tutoriel généraliste sur ça pour bien mettre les choses à plat.

[peter27x]

Override sert surtout à dire que je "redéfinie" le traitement hérité sans pour autant briser la virtualité de la méthode dans la classe de base.

Par définition une méthode abstraite (abstract) est virtuelle (virtual). Une méthode abstraite définit un prototype de méthode mais qui devra être redéfinit dans les classes hérités (donc pas d'implémentation dans la classe de base).

Néanmoins ça c'est la base de chez base du concept d'héritage des classes, à mon avis tu ferais mieux de chercher un bon tutoriel généraliste sur ça pour bien mettre les choses à plat.

Ok, mais j'ai pas vu dans ta réponse ceci dit une explication qui distingue clairement la fonction des mots clé "abstract" et "virtal" ... ? Je crois que Shail maitrise bien cette particularité.

Sinon, pour info, j'ai une année de spécialisation en POO pure, donc les notions d'heritage, ça va, j'en ai assez mangé même si ça fait un petit moment que j'ai pas trop pratiqué

Là c'est surtout essayer de comprendre comment Delphi gère tout ça, et notamment la différence entre ces deux mots-clés à priori assez proches, non ?

[Aquaa]

Ok, mais j'ai pas vu dans ta réponse ceci dit une explication qui distingue clairement la fonction des mots clé "abstract" et "virtal" ... ? Je crois que Shail maitrise bien cette particularité.

Sinon, pour info, j'ai une année de spécialisation en POO pure, donc les notions d'heritage, ça va, j'en ai assez mangé même si ça fait un petit moment que j'ai pas trop pratiqué

Là c'est surtout essayer de comprendre comment Delphi gère tout ça, et notamment la différence entre ces deux mots-clés à priori assez proches, non ?

Tiré de l'aide de Delphi

Comparaison des méthodes virtuelles et des méthodes dynamiques

D'un point de vue sémantique, les méthodes virtuelles et les méthodes dynamiques sont équivalentes. Elles ne diffèrent que dans l'implémentation de la répartition de l'appel de méthode à l'exécution. Les méthodes virtuelles sont optimisées pour la rapidité alors que les méthodes dynamiques permettent d'optimiser la taille du code.

En général, les méthodes virtuelles constituent la manière la plus efficace d'implémenter un comportement polymorphique. Les méthodes dynamiques sont utiles quand une classe de base déclare de nombreuses méthodes pouvant être surchargées qui sont héritées par de nombreuses classes dérivées d'une application mais rarement surchargées.

Remarque

N'utilisez les méthodes dynamiques que s'il existe un avantage clair et observable. Utilisez habituellement les méthodes virtuelles.

[peter27x]

Tiré de l'aide de Delphi

si je pige ton extrait du F1, "methode dynamique" veut dire methode avec le mot clé ABSTRACT ?

[Aquaa]

inversement

Les méthodes abstraites doivent être déclarées en spécifiant la directive abstract après virtual ou dynamic. Par exemple*:

Code :

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

procedure FaireQuelquechose; virtual; abstract;

[peter27x]

inversement

Les méthodes abstraites doivent être déclarées en spécifiant la directive abstract après virtual ou dynamic. Par exemple*:

Code :

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

procedure FaireQuelquechose; virtual; abstract;

C'est ce que je demande en fait, voilà : quelle est la diff entre "virtual" et "abstract" ???

En fait, là, j'ai même pas Delphi d'ouvert, je suis en phase de conception (UML SVP... ), je viens trainer de tps en tps ici bas pour pas perdre le fil Delphiste...

[Cl@udius]

Salut

C'est ce que je demande en fait, voilà : quelle est la diff entre "virtual" et "abstract" ???

Guymelef a déjà répondu à ta question:

Par définition une méthode abstraite (abstract) est virtuelle (virtual). Une méthode abstraite définit un prototype de méthode mais qui devra être redéfinit dans les classes hérités (donc pas d'implémentation dans la classe de base).

@+

[peter27x]

Salut


Guymelef a déjà répondu à ta question:


@+

Donc, on peut mettre:
func... virtual;

ou bien:
func... virtual; abstract;

mais pas :
func... abstract;

C'est ça ?

[Cl@udius]

C'est ça.

Une méthode abstraite est par nature virtuelle (ou dynamique).

@+

[peter27x]

C'est ça.

Une méthode abstraite est par nature virtuelle (ou dynamique).

@+

J'ai lu toutes vos réponse, suis allé chercher des infos dans le F1 de Delphi, mais je vois tjrs pas clair dans tout ça... Je trouve que ça manque d'explications simples et claires.

Il y a 5 "types" de methodes de classe en Delphi:

Statique
Dynamique
Dynamique abstraite
Virtuelle
Virtuelle abstraite

Statique : on définit le contenu dans la classe, la fonction sera héritée des classes enfants : pourra elle être surchargée (override) ?

dynamique : ???
dynamique abstraite : ??? + elle doit forcément être définie dans les enfants

virtuelle : elle peut être redéfinie dans les enfants
virtuelle abstraite : elle doit forcément être redéfinie chez les enfants

J'ai beau me remémorer ma spécialisation POO (ça date certes de 97), je me rappelle bien l'héritage, la surcharge, le polymorphisme... mais là, version Delphi, je pige pas tout dans cette multiplicité sémantique... !

Je vois pas le lien entre, d'une part le type de déclaration parmis les 5 types cités plus haut, et d'autre part, les manières autorisées ou pas de la "récupérer" chez les enfants...

Désolé si je vous semble lent et bête.

[Aka Guymelef]

Encore un extrait de bon vieux F1

Comparaison des méthodes virtuelles et des méthodes dynamiques

D'un point de vue sémantique, les méthodes virtuelles et les méthodes dynamiques sont équivalentes. Elles ne diffèrent que dans l'implémentation de la répartition de l'appel de méthode à l'exécution. Les méthodes virtuelles sont optimisées pour la rapidité alors que les méthodes dynamiques permettent d'optimiser la taille du code.

En général, les méthodes virtuelles constituent la manière la plus efficace d'implémenter un comportement polymorphique. Les méthodes dynamiques sont utiles quand une classe de base déclare de nombreuses méthodes pouvant être surchargées qui sont héritées par de nombreuses classes dérivées d'une application mais rarement surchargées.

En clair la différence se situe au niveau des binaires rendus après compilation mais d'un point de vue sémantiques les deux reviennent au même. Une méthode dynamique ou virtuelle est candidate à être redéfinie via un override. Et pour l'abstraction, c'est pareil.

Donc si tu es au niveau de la modélisation UML et bien la différence entre virtual et dynamic n'est pas à être dedans, tu dois juste définir si ce sont des méthodes statiques, virtuelles ou abstraites. Choisir après entre virtual et dynamic relève déjà de la partie code et plus exactement tunning de l'application à mon sens.

[peter27x]

Encore un extrait de bon vieux F1



En clair la différence se situe au niveau des binaires rendus après compilation mais d'un point de vue sémantiques les deux reviennent au même. Une méthode dynamique ou virtuelle est candidate à être redéfinie via un override. Et pour l'abstraction, c'est pareil.

Donc si tu es au niveau de la modélisation UML et bien la différence entre virtual et dynamic n'est pas à être dedans, tu dois juste définir si ce sont des méthodes statiques, virtuelles ou abstraites. Choisir après entre virtual et dynamic relève déjà de la partie code et plus exactement tunning de l'application à mon sens.

Ou là mais UML n'est absolument pas dans ma problématique là ! Aucun rapport pour ce qui me concerne dans cette file ci

J'en suis juste à la modélisation fonctionnelle tu sais... Le modèle de classe et tout le toutim c'est pour plus tard...

Ici je voulais juste avoir des super lumières (vu que c'est un super forum !) sur la sémantique Delphienne... D'autant plus que l'appli en question ne contiendra guère plus de 2 à 4 classes à tout casser... !