Envoyé par
Bernard B
Bien il semble que les interface permettent de séparer l'utilisation de la mécanique interne. Mais dans la POO de base c'est bien la différence entre public et private.
L'article dont retwas me donne le lien, je l'avais déjà parcouru il y a un certain temps. Je l'ai relu et je suis toujours aussi dubitatif. C'est compliqué et finalement on ne voit pas surgir l'élément incontournable qui fait que l'on s'y colle.
Je n'avais pas tout suivi et rebelote c'est compliqué pour quoi ?
Je dois dire que l'exemple que donne Paul est assez impressionnant. Perso je n'y comprend rien ! et le pire c'est que l'on ne devine pas à quoi cela peut conduire.
La POO suivant son implémentation ce n'est pas toujours simple, mais les interfaces ressemblent à la forêt vierge.
Les cerveaux plus jeunes sont certainement plus malléables mais là le mien à atteint le seuil de son incompétence !
les interfaces c'est un juste un outil, des fois il est pratique de s'en servir.
1) pour les DLL
dans
Delphi 7 Studio, et notamment le chapitre 19 qui est
disponible en ligne, je parle entre autre des plugins. Il n'est pas possible de partager un objet entre une DLL et un EXE sous Delphi, mais avec une Interface ça ne pose aucun problème.
2) l'héritage multiple
dans la POO si tu veux manipuler deux objets différents par le même code, ils doivent avoir un ancêtre commun. Grâce aux interfaces tu peux lever cette limitation très facilement (j'en parle
ici d'ailleurs).
techniquement, une interface est un tableau de méthodes, dans Delphi 7 Studio je montre d'ailleurs qu'on peut très bien manipuler les interface à partir d'un simple RECORD
Quand un objet implémente une interface donnée, c'est qu'il est capable de fournir un tableau contenant l'adresse de toutes les méthodes de l'interface dans un ordre établi. Du coup l'objet qui utilise ce tableau peu invoquer la méthode n°x car il sait que c'est la fonction attendue.
tu peux même faire les choses à l'envers, imaginons que tu as deux objets qui ont une fonction Draw(Canvas: TCanvas), les deux fonctions sont totalement différentes , ne sont pas virtuelles, mais tu voudrais pouvoir appeler indifféremment l'une ou l'autre en plaçant ces objets dans un TList, ce n'est pas possible en POO, mais si tu ajoutes l'Interface suivante à ces deux objets;
1 2 3 4 5 6 7 8 9 10 11 12 13
|
IDraw = interface
// ajouter ici un GUID généré par Ctrl+Shift+G
procedure Draw(Canvas: TCanvas);
end;
TObjet1 = class(..., IDraw)
procedure Draw(Canvas: TCanvas);
end;
TObjec2 = class(..., IDraw)
procedure Draw(Canvas: TCanvas);
end; |
tu peux manipuler les deux objets comme des TObject et faire un
(TObject(List[Index]) as IDraw).Draw(Canvas);et ça c'est plutôt pratique...le seul bémol c'est que toute interface implique l'usage de IInterface qui ajoute AddRef et Release pour gérer la durée de vie de l'objet et si tu ne dérives pas de TInterfacedObject ou TComponent tu dois aussi ajouter ces méthodes.
Envoyé par
retwas
@PaulTOTH : Exactement c'est vrai qu'en débogage faut parfois aller chercher un peu plus loin, mais c'est une autre façon de coder que je trouve peut être plus "moderne", je vois d'ailleurs que tu les utilises pour le TMouse3D
mais je n'ai pas la prétention de pouvoir t'apprendre quelque chose
si tu parles de ce
TMouse3D, c'est normal, c'est un objet COM
3 |
0 |