Discussion :

[Suryavarman]

On peut en delphi utiliser une property et indiquer qu'elle implemente une interface. Ce qui évite de tout récrire les fonctions et procédures de l'interface pour juste rappeler les mêmes avec un objet respectant cette interface.
exemple :

Code :

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

1
2
3
4
5
TTruc class ( TInterfacedObjects, IExemple )
  FExemple : IExemple ;
 
  public
    property Exmple : IExemple read FExemple implements IExemple ; // on peut aussi utiliser une fonction GetExemple pour préparer l'interface juste avant.

Mais cet implements à des limites voici les deux cas qui m'ont posés problèmes.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ITruc = interface( IExemple )
 
TTruc class ( TInterfacedObjects, ITruc )
  FExemple : IExemple ;
 
  public
    property Exmple : IExemple read FExemple implements IExemple ;
// erreur IExemple ne fait pas parti des interfaces de TTruc
 
ITruc = interface( IExemple )
 
TTruc class ( TInterfacedObjects, ITruc, IExemple  )
  FExemple : IExemple ;
 
  public
    property Exmple : IExemple read FExemple implements IExemple ;
// erreur les méthodes de IExemple ne sont pas implémentées

Ceci oblige d'utiliser des as et des support de partout.

Pour moi cet implements est incomplet, c'est une tentative de rattraper cette utopie de ne pas avoir de multi héritage.

[ShaiLeTroll]

Il n'y a pas de limite à implements, c'est que tu n'as pas compris sa fonctionnalité ...

cela permet dans un objet qui implémente beaucoup d'interface de déléguer l'implémentation à une autre classe, c'est très utile pour un fonctionnement polymorphique utilisant un fabrique de classe qui sélectionne en runtime la bonne classe d'implémentation (sans le savoir à l'avance) ... ou pour "modulariser" le code ...

Sinon, ton code est tout simplement incomplet voire faux, tu fais de l'hértiage d'une interface et de son ancêtre, ce qui n'a aucun intéret puisque l'une incluse dans l'autre, déjà c'est une erreur de conception, mais si l'on passe déjà cette erreur humaine, eh bien, le langage réagit logiquement, il réclame une implémenation de la classe et une implémentation de son ancêtre et cela indépendemment de la notion d'héritage

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
type
  IExemple = interface
     procedure P1;
  end;
 
  ITruc = interface( IExemple )
     procedure P2;
  end;
 
  TTruc = class (TInterfacedObject, ITruc, IExemple)
  private
    FExemple : IExemple ;
    FTruc : ITruc ;
  public
    property Exmple : IExemple read FExemple implements IExemple ; // même si Truc implémente par héritage IExemple, il faut quand même lui fournir l'implémentation de l'ancêtre
    property Truc : ITruc read FTruc implements ITruc ; // faut aussi l'implémenter celui là, et d'ailleurs, l'implémentation peut surcharger celle déjà fait par un implémentateur de l'ancêtre ...
  end;

[Suryavarman]

Merci ShaiLeTroll mais une question FTruc : ITruc ; tu lui met quoi dedans à quoi va ressembler cet objet ?

FTruc ne peu être un ITruc sans êtres aussi un IExemple car être un ITruc implique forcément que c'est aussi un IExemple. Je vois bien que les interfaces sont à prendre comme des contrats indépendants des autres.

Mais j'ai pas choisi delphi(en fait j'ai pas eu le choix :p ) pour réfléchir mais pour aller vite.

[ShaiLeTroll]

Je suppose que tu es un dev Java ou c++, tu semble ne pas aimer Delphi ... bon, je t'avoue que je n'ai que peu fait d'interface, j'y ai touché plus par curiosité que par necessité, je fais bcp de méthodes abstraites que je surcharge au sein d'un même programme, mais peu d'inter-opérabilité entre programmes ...

tu auras

Code :

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

1
2
3
4
5
6
7
8
9
type
  TExempleImpl = class (TInterfacedObject, Exemple)
    procedure P1;
  end;
 
  TTrucImpl = class (TInterfacedObject, ITruc)
    procedure P1;
    procedure P2;
  end;

ou même, en théorie, tu dois pouvoir faire

Code :

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

1
2
3
4
5
6
7
8
type
  TExempleImpl = class (TInterfacedObject, Exemple)
    procedure P1;
  end;
 
  TTrucImpl = class(TExempleImpl, ITruc)
    procedure P2;
  end;

tout dépend si tu souhaite que ton implémentation soit la même pour les deux ou pas ... tu as choisi un cas bien vicieux d'héritage ...

Code :

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

1
2
3
4
5
6
7
8
9
10
var
  ObjetTruc: TTruc;
  InterfaceTruc: ITruc;
begin
  ObjetTruc:= TTruc.Create;
  ObjetTruc.FExmple := TExempleImpl.Create();
  ObjetTruc.FTruc := TTrucImpl.Create();
 
  InterfaceTruc:= ObjetTruc;
  InterfaceTruc.P1; // Et la question, que se passe-t-il ? il prend Exmple.P1 ou Truc.P1, ... normalement comme Truc.P1 masque Exemple.P1, il doit lancer Truc ... end;

par prudence, je prendrais je ferais ceci

Code :

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

1
2
3
4
5
6
7
8
9
type
  TExempleImpl = class (TInterfacedObject, IExemple)
    procedure P1; virtual;
  end;
 
  TTrucImpl = class(TExempleImpl, ITruc)
    procedure P1; override;
    procedure P2;
  end;

ainsi, on est sure que P1 est écrasé, et qu'il n'y a pas de mauvaise surprise ...

[Suryavarman]

Code :

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

1
2
3
4
5
6
7
8
9
 
type
  TExempleImpl = class (TInterfacedObject, Exemple)
    procedure P1;
  end;
 
  TTrucImpl = class(TExempleImpl, ITruc)
    procedure P2;
  end;

Yep cette solution est la meilleur mais j'aime pas ça, être obligé de créer des classes intermédiaires qui ne servent cas décrire une hiérarchie relative à l'objet qu'on veut implémenter ça me gène. Car après si je veux créer TTruc2 avec un ITruc2 qui "dérive" de IExemple, il me faudra créer TTrucImpl2.

( je suis dev c++ seulement le soir et dev delphi le jour )
( j'aime pas delphi car ils ont choisi de prohiber le multi héritage, ils ont décidé de passer par des interfaces, et de dire que le multi héritage c'est le mal. Dans c'est cas les langages informatiques sont le mal car un programmeur qui fait n'importe quoi fera n'importe quoi quelques soit le langage, enfin je trouve que c'est se tirer une balle dans le pied alors que delphi est conçu pour coder vite, là on se retrouve avec des pans de code dupliquer ,des classe intermédiaires ou d'énormes classes de base .

[ShaiLeTroll]

Au fait, tu n'es pas non plus obligé d'utiliser implements, la déléguation d'implémentation a un but objet précis, génération associé à une sorte de ClassFactory au près de laquelle les implémentateurs se recensent et en fonction de certains propriété la fabrique va choisir tel ou tel implémentateur qui d'ailleurs en delphi peu se faire entièrement par virtualisation des méthodes et du constructeur (comme le TComponent), ... mais c'est peut-être moins dans les normes de l'implémentation d'interface ...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
type
  IExemple = interface
     procedure P1;
  end;
 
  ITruc = interface(IExemple)
     procedure P2;
  end;
 
  TTruc = class (TInterfacedObject, IExemple, ITruc)
     procedure P1;
     procedure P2;
  end;
 
  ITruc2 = interface( IExemple )
     procedure P3;
  end;
 
  TTruc2 = class (TInterfacedObject, IExemple ITruc2)
     procedure P1; 
     procedure P3;
  end;

OU avec plus de classe (ce qui réduit le nom de fois où l'on recopie P1, d'ailleurs, c'est la que le implements permet d'éviter le virtual par un objet d'implémentation externe ...)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
type
  IExemple = interface
     procedure P1;
  end;
 
  TExemple = class (TInterfacedObject, IExemple)
     procedure P1; virtual;
  end;
 
  ITruc = interface(IExemple)
     procedure P2;
  end;
 
  TTruc = class (TExemple, ITruc)
     procedure P2;
  end;
 
  ITruc2 = interface( IExemple )
     procedure P3;
  end;
 
  TTruc2 = class (TExemple, ITruc2)
     procedure P1; override;
     procedure P3;
  end;

... un programmeur qui fait n'importe quoi fera n'importe quoi quelques soit le langage .

Tu n'imagines même pas à quel point

...delphi est conçu pour coder vite, là on se retrouve avec des pans de code dupliquer

lol, c'est vrai que poser une architecture objet avec des interface, de l'héritage, cela permet de coder vite, , ça me fait rire, car coder vite dans 90% des cas que j'ai vu c'est faire du procédural et utiliser des Tstringlist pour tout et rien ... je ne sais pas combien tu as écumé de boites (moi 5 déjà) et lol, va demander ce qu'un un virtual en delphi, 75% des dev que j'ai cottoyé m'ont répondu "Euh ? Stéphanie de Monaco" ... Perso, j'ai du comprendre le virtual à mon premier thread, genre au bout de 2 ans et demi de programmation (j'étais apprenti durant mon DUT puis ma Licence Pro) ...

...
j'aime pas delphi car ils ont choisi de prohiber le multi héritage

Je ne crois même pas l'avoir appris, ça existe en java ? euh ben non, surement que finalement, ce fonctionnement n'était pas si utile, ...

Sinon le modèle objet n'est pas aussi employé que cela, j'ai fait aussi beaucoup de code procédural avec en paramètre des structures, la seule chose que je changerais dans ces codes c'est l'utilisation du polymorphisme au lieu d'un vilain case, mais toutes mes fonctions resterait des méthodes de classe car ce n'était que de la manipulation de données en entrée puis en sortie pour comuniquer avec un automate ...

Tiens j'ai vu des codes dits "objets" très crades à base de frame qui mélange métier\présentation ou de datamodule servant comme ancêtre à des objets métiers rempli à ras-bord de composant ... puis l'absence de libération alors que l'on créé des instances à tout va ... alors, oui, déjà que les trucs simples ou élémentaires, tout le monde ne les maitrise pas, alors le multi-héritage ... ça me parait encore un truc compliqué qui ne semble pas forcément utile, j'ai même du mal à en voir l'utilité dans l'ensemble de tous les projets auquels j'ai participé, et puis, ne serait-ce pas une difficulté technique (je pense au virtual qui semble être propre au delphi) lors de l'héritage triangulaire qui ai poussé les auteurs du pascal object à renoncer à ce fonctionnement ?

Voilà, bon, je dérive un peu avec mes états d'âme mais on a pas toujours le temps de faire beau, donc vive la TStringList ...

[Kaféine]

tu fais de l'hértiage d'une interface et de son ancêtre, ce qui n'a aucun intéret puisque l'une incluse dans l'autre, déjà c'est une erreur de conception,

pour moi l'héritage d'interface a des intérêts et je vois pas en quoi c'est une erreur de conception

exemple je declare une interface IEvent

et je dérive 2 interfaces: IMouseEvent et IKeyboardEvent

du coup, polymorphisme oblige, je peux ecrire une méthode genre

Code :

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

1
2
 
procedure DoEvent(const Evt: IEvent);

[Paul TOTH]

tient je viens de découvrir quelque chose

je ne savais pas qu'on pouvais déléguer une interface comme ça

bon faut dire que j'utilise assez peu les interfaces en même temps

Code :

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

1
2
3
4
5
6
7
8
9
 
type
  TExempleImpl = class (TInterfacedObject, Exemple)
    procedure P1;
  end;
 
  TTrucImpl = class(TExempleImpl, ITruc)
    procedure P2;
  end;

Yep cette solution est la meilleur mais j'aime pas ça, être obligé de créer des classes intermédiaires qui ne servent cas décrire une hiérarchie relative à l'objet qu'on veut implémenter ça me gène. Car après si je veux créer TTruc2 avec un ITruc2 qui "dérive" de IExemple, il me faudra créer TTrucImpl2.

ben ça dépend, ce que tu es obligé de faire c'est d'implémenter les interfaces dont tu déclares que ta classe les implémente...ça parait logique non ? libre à toi de ne pas déclarer cette dépendance

( je suis dev c++ seulement le soir et dev delphi le jour )
( j'aime pas delphi car ils ont choisi de prohiber le multi héritage, ils ont décidé de passer par des interfaces, et de dire que le multi héritage c'est le mal. Dans c'est cas les langages informatiques sont le mal car un programmeur qui fait n'importe quoi fera n'importe quoi quelques soit le langage, enfin je trouve que c'est se tirer une balle dans le pied alors que delphi est conçu pour coder vite, là on se retrouve avec des pans de code dupliquer ,des classe intermédiaires ou d'énormes classes de base .

alors là je suis pas d'accord avec toi.

1) pour moi c'est le multihéritage qui est une hérésie et non son absence
2) les interfaces n'ont pas pour but de supporter le multihéritage...mais de supporter...les interfaces telles qu'on les trouvent dans COM.

Dans les versions de Delphi ne supportant pas les interfaces il fallait déclarer des classes virtuelles ce qui était lourd et pénible.

Tu viens du c++, il faut bien voir que le langage Delphi a évolué en même temps que le produit, et d'une version à l'autre tu as parfois des modifications profondes dans le langage, avec des switch de compilation pour assurer la compatibilité ascendante. ça choque parfois les programmeurs d'autres langage, mais c'est ce qui a permis à Borland d'avoir un langage qui permet le portage d'une application existante de Win16 (voir DOS) vers Win32, Linux et dotNet avec le minimum de modification dans le code. Au lieu de garnir le source de #ifdef ou de #define, c'est le langage qui s'adapte

EDIT: --> au fait, Delphi ne supporte pas l'héritage multiple, donc essayer de le faire malgré tout c'est forcément casse gueule. Le plus simple et de ne pas utiliser ce concept...ce qui est tout à fait possible avec un peu de méthode

[tourlourou]

et puis, ne serait-ce pas une difficulté technique (je pense au virtual qui semble être propre au delphi) lors de l'héritage triangulaire qui ai poussé les auteurs du pascal object à renoncer à ce fonctionnement ?

quid de Lazarus, sur ce point ?

[Kaféine]

Delphi ne supporte pas l'héritage multiple...

Heu justement si avec l'aide des interfaces!

exemple:

une interface IHomme => Homme sont implementation
une interface IGrenouille => Grenouille sont impl

et une implémentation de l'homme-grenouille, supportant les 2 interfaces ci dessus. si c'est pas de l'héritage multiple ou de la simulation ca alors j'ai rien compris....

[Paul TOTH]

Heu justement si avec l'aide des interfaces!

exemple:

une interface IHomme => Homme sont implementation
une interface IGrenouille => Grenouille sont impl

et une implémentation de l'homme-grenouille, supportant les 2 interfaces ci dessus. si c'est pas de l'héritage multiple ou de la simulation ca alors j'ai rien compris....

ben non c'est pas de l'héritage multiple

l'héritage multiple c'est quand tu as une belle hiérarchie d'objets et que tout d'un coup ça colle plus.

tu as d'un côté le vélo et de l'autre l'homme et tu te dis que ça serait cool de créer une classe "homme en chaise roulante" qui prend un peu de l'homme et un peu du vélo.

en d'autre termes, ton homme-grenouille et à la fois un homme et une grenouille, mais n'a rien de l'homme-grenouille

[Kaféine]

Pourtant mon homme-grenouille supporte les caracteristiques de l'homme et de la grenouille :\ c'est ce qui le rend homme-grenouille à mon sens.

maintenant "prendre un peu" de chaque reviendrait à affiner la granularité des interfaces non?

[Paul TOTH]

c'est bien pour ça que j'ai pris l'exemple d'un homme en chaise roulante, il a beau rouler, c'est pas un vélo...même si c'est un homme...qui ne marche pas.

mais bon, de toute façon les langages qui supportent l'héritage multiple s'appuient sans doute sur des table de méthodes similaires aux interfaces pour retrouver leurs petits

mais comme je le disais au départ, les interfaces ne sont pas là POUR l'héritage multiple, mais pour supporter la interfaces COM...vouloir faire de l'héritage multiple sous Delphi est une erreur à mon sens.

[ShaiLeTroll]

pour moi l'héritage d'interface a des intérêts et je vois pas en quoi c'est une erreur de conception

ce n'est pas l'héritage d'interface qui est une erreur de conception mais de vouloir implémenter une interface et son ancêtre, ce qui est inutile puisque ce denier est inclu ....

une interface IEtreVivant => EtreVivant
une interface IHomme herite de IEtreVivant => Homme sont implementation
une interface IGrenouille herite de IEtreVivant => Grenouille sont impl

le problème de vouloir mettre dans Homme l'interface IHomme et IEtreVivant qui est déjà incluse dans homme, je ne parlais en aucun cas de l'implémentation de deux classes héritées ayant le même ancêtre ...

c'était le cas avec

Code :

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

TTruc = class (TInterfacedObject, IExemple, ITruc)

ITruc étant un IExemple, ce n'a pas de sens, c'est cela que je critiquais, et rien d'autre ...

même principe si tu implémente IMouseEvent, inutile d'implementer IEvent qui l'est forcément par héritage ... pour moi, c'est une énorme de conception ou de compréhension même de l'héritage ...

et puis, ne serait-ce pas une difficulté technique (je pense au virtual qui semble être propre au delphi) lors de l'héritage triangulaire qui ai poussé les auteurs du pascal object à renoncer à ce fonctionnement ?

quid de Lazarus, sur ce point ?

Quel point ? Virtual ? Multi-Héritage ?
Euh, Lazarus résoudrait-il le problème, est-ce que cela que tu voulais dire Tourlourou ?
Quand j'ai dit propre au Delphi, ne connaissant que le Pascal Objet dans Delphi, je ne peux me prononcer qu'à ce sujet ...

pour moi c'est le multihéritage qui est une hérésie et non son absence

n'aurais-je pas lu cela dans un livre d'Olivier DAHAN et ...de Paul TOTH

[Kaféine]

dans le cas

Code :

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

1
2
 
TTruc = class (TInterfacedObject, IExemple, ITruc)

il n'y a pas de classe ancetres implementant l'interface IExemple...

si je cree une classe TTest dérivant de TInterfacedObject et que je veux qu'elle implemente IMouseEvent.

je devrais implementer dans celle ci les methodes de IMouseEvent et de IEvent car IMouseEvent derive de IEvent.

si j'écris :

Code :

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

1
2
 
 TTest = class(TInterfacedObject, IMouseEvent)

les methodes de l'interface IEvent devront etre implementé dans TTest, mais c'est pas pour autant que je pourrai ecrire un truc du genre

Code :

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

1
2
 
DoEvent(TTest.Create);

car TTest n'implemente pas IEvent, seulement via IMouseEvent

du coup la solution c'est d"ecrire

Code :

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

1
2
 
TTest = class(TInterfacedObject, IMouseEvent, IEvent)

[tourlourou]

j'ai du mal à vous suivre dans tous ces entrelacs !

pour Lazarus, c'était juste de la curiosité (virtual et multi-héritage) ; et puis s'ils implémentaient l'héritage multiple, on saurait au moins que ce n'est pas sur les conseils de merlin !

[Paul TOTH]

je suis tombé par hasard sur cette page qui est relativement intéressante à lire, elle parle des classes objets sous Delphi, C#, C++ et Java

[Suryavarman]

je viens de comprendre ce que tu voulais dire ShaiLeTroll par :

vouloir implémenter une interface et son ancêtre, ce qui est inutile puisque ce denier est inclu

( l'interface et son "ancêtre" forme un tout )

Mon patron vient de regarder en détail l'implements et je l'utilise mal, très mal:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
TExemple = class(TAggregatedObject, IExemple) // on est même pas obligé de mettre IExemple
// seul les classes dérivant de TAggregatedObject peuvent ( et seulement ) être utilisées par un implements .
   constructor Create(const Controller: IUnknown);
   procedure DeIEXemple ;
end;
 
TBidule = class( TInterfacedObject, IExemple )
  private
    FExemple : TExemple ;
 
  public
  property Exemple : TExemple read FExemple  implements IExemple ;
  // si on met IExemple à la place de TExemple le ref count bug et l'interface ne se libère pas, cela vient de TAggregatedObject .
...

Donc si vous voulez utilisez l'implements, les classes qui y seront utilisées ne seront faites que pour ça ( sauf si vous rajouter une couche à TAggregatedObject ). Résultat je vais virer tout les implements qui faisaient plein de memory leaks (mettez dans votre MainForm.FormCreate ReportMemoryLeaksOnShutdown := true; ).

[ShaiLeTroll]

ReportMemoryLeaksOnShutdown

Encore une nouveaute BSD ? intéressant, cela remplace le bon vieux MemorySleuth ...

@Kaféine,
Bon exemple, c'est pour pour moi une lacune dans l'héritage de l'implémentation d'interface ... car normelment si TTest implémente IMouseEvent, il devrait pouvoir être utiliser comme IEvent puisque IMouseEvent hérite de IEvent

Je viens de tester, c'est effectivement bloquant et explique la double implémentation Interface et ancêtre, et je m'en excuse auprès de Suryavarman d'avoir penser à une erreur de conception, mais en fait, la véritable limite du implements c'est ça ! hum, on apprend tous les jours !

Sinon, la Délégation à une propriété via une classe, je crois que c'est apparu avec Delphi 7 (à vérifier) justement pour résoudre des problèmes de la Délégation à une propriété via une Interface, et ton patron a bien raison !

[Franck SORIANO]

Encore une nouveaute BSD ? intéressant, cela remplace le bon vieux MemorySleuth ...

Oui, c'est une nouveauté de BDS 2006. Ils ont remplacé le gestionnaire de mémoire de Delphi par celui de FastMM.

Maintenant en standard avec BDS2006 cette option permet de savoir s'il existe des memory leak dans l'appli, au moment de la sortie. Par contre elle ne permet pas de savoir avec précision ou se trouve le memory leak.
En revanche, on peut toujours utiliser FastMM pour obtenir une trace précise de l'allocation du bloc mémoire. Ca permet de trouver la ligne exacte dans le source qui a effectuer l'allocation mémoire.