Discussion :

[Bruno75]

Quels sont les avantages et inconvénients comparés de l'utilisation des méthodes d'objets et de l'utilisation de la surcharge des méthodes.

[AlDel]

Bonjour,

Je ne comprend pas trés bien ta question, la surcharge des méthodes rentre dans l'enrichissement d'un objet, cela revient à dire que l'objet de base ne te convient pas : tu l'adaptes à ta convenance, s'il te convient tel quel : tu prends ses methodes sans les changer, donc je ne vois pas de comparaisons à faire la dessus.(Si j'ai bien compris)

[Bruno75]

A priori je suis d'accord. Cependant, j'ai utilisé récemment les composants TMS Grid, en particulier TAdvStringGrid. Et Y a plein de fonctions qui ne sont pas à proprement parler des événements. En particulier OnFixedCell ou qqch comme ca qui permet de déterminer pour chaque ligne ou colonne si elle est fixe.

Ca n'a rien d'un événement. Je trouve qu'il serait plus "correct" de prévoir la fonction IsCellFixed virtuelle que l'utilisateur se chargerait de surcharger.

Pourtant, les développeurs de TMS Software ont choisi la technique OnFixedCell.

L'un des avantages est bien évidemment de l'avoir dans l'inspecteur d'objet.

[Bernard Grosdoy]

Meme remarque que Alain : Je ne comprend pas bien

La question n'est elle pas plutot celle du polymorphisme de déclaration de methode?

[gord's]

L'un des avantages est bien évidemment de l'avoir dans l'inspecteur d'objet.

Pour qu'une property apparaise dans l'inspecteur, il suffit qu'elle soit déclarée sous 'published'. Pas besoin que ce soit un event.

[Bruno75]

Bon faut que je réexplique ce que je veut dire.

Prenons l'exemple du message Click. Lorsque le message click est envoyé à une fenêtre, il est réceptionné par la fenêtre qui dans le cas où la propriété OnClick a été définie lance la fonction correspondante.

On aurait très bien pu avoir le lancement d'une procédure Click virtuelle ne faisant rien dans la fenêtre de base, procédure que l'utilisateur aurait surchargée.

Le gros intérêt est que la manière dont cela a été fait permet l'utilisation que l'on connaît à savoir double cliquer dans l'inspecteur et attérir directement au bon endroit.

La question est cela a-t-il un inconvénient ?

En particulier quand la fonction n'est pas reliée à un message windows mais un événement d'un composant du style OnFixedCell.

[Pierre Castelain]

La grosse différence est que si tu ne veux pas utiliser le mécanisme d'évènement, tu vas être obligé de dériver la classe à chaque fois que tu veux t'en servir. En effet, la surcharge d'une méthode ne peut se faire que dans une classe fille. Imagine un peu une fenêtre dans laquelle il y aurait 5 ou 6 composants de ce type. Tu serais obligé de créer autant de classes dérivées. En plus, tu ne pourrais pas utiliser l'aspect RAD puisque tu ne peux poser un composant sur une fiche que s'il est enregistré dans la VCL. Très lourd, très, très lourd...
Or avec le mécanisme d'évènement Delphi, c'est une méthode d'un autre objet (généralement la fenêtre) qui est utilisée. Donc pas besoin de dériver autre chose que TForm. Et comme tu es obligé de dériver TForm pour créer une nouvelle fenêtre, cela ne demande pas de code supplémentaire. En plus, tu peux très bien changer le gestionnaire à la volée, ce qui peut être pratique dans certains cas.
Pour terminer, il faut résonner en terme de classe et d'instance. La surcharge fonctionne au niveau de la classe alors que les gestionnaires d'évènement fonctionnent au niveau de l'instance.

[Bruno75]

Pour terminer, il faut résonner en terme de classe et d'instance. La surcharge fonctionne au niveau de la classe alors que les gestionnaires d'évènement fonctionnent au niveau de l'instance

C'est exactement ce que je cherchais. Merci.