Discussion :

[Paul TOTH]

oui enfin mon idée était que cela permet de ne pas instancier la version 1 tant qu'on en a pas besoin et DirectX présente régulièrement des interface qui n'ont plus rien à voir avec celle de la version précédente

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
 
type
 IVersion1=interface
  ['{C04A6AE1-8F31-4893-A255-79E49AAFDFE9}']
  procedure SayHello;
 end;
 
 IVersion2=interface
  procedure SayHello;
 end;
 
 TVersion1=class(TInterfacedObject,IVersion1)
  procedure SayHello;
  destructor Destroy; override;
 end;
 
 TVersion2=class(TInterfacedObject,IVersion1,IVersion2)
 private
  function GetVersion1:IVersion1;
 public
  destructor Destroy; override;
  procedure SayHello;
  property Version1:IVersion1 read GetVersion1 implements IVersion1;
 end;
 
 
destructor TVersion1.Destroy;
begin
 ShowMessage(ClassName+' say good bye');
 inherited;
end;
 
procedure TVersion1.SayHello;
begin
 ShowMessage(ClassName+' say hello');
end;
 
destructor TVersion2.Destroy;
begin
 ShowMessage(ClassName+' say good bye');
 inherited;
end;
 
function TVersion2.GetVersion1:IVersion1;
begin
 ShowMessage('New Version1');
 Result:=TVersion1.Create;
end;
 
procedure TVersion2.SayHello;
begin
 ShowMessage(ClassName+' say hello');
end;
 
procedure TForm1.FormCreate(Sender: TObject);
var
 v2:IVersion2;
 v1:IVersion1;
begin
 v2:=TVersion2.Create;
 v2.SayHello;
 v2.QueryInterface(IVersion1,v1);
 v1.SayHello;
end;

par contre, avec ce code on retombe sur une fuite mémoire si on écrit

Code :

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

1
2
3
4
5
 
begin
 v1:=TVersion2.Create;
 v1.SayHello;
end;

[DenDemble]

en scannant les sources de mon disque dur j'ai trouvé un seul exemple d'utilisation d'implements, mais il est intéressant, car il m'a fait apparaitre un aspect d'implements auquel je n'avais pas pensé :

l'exemple d'utilisation est jclSchedule.pas de la JCL (dans common)
où sont implementées dans une classe TSchedule différentes interfaces
qui ont en commun certaines propriétés et noms de procédure.

les interfaces implémentées dans TSchedule sont

Code :

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

1
2
3
4
5
6
 
    property DailyFreq: TDailyFreq read FDailyFreq implements IJclScheduleDayFrequency;
    property DailySchedule: TDailySchedule read FDailySchedule implements IJclDailySchedule;
    property WeeklySchedule: TWeeklySchedule read FWeeklySchedule implements IJclWeeklySchedule;
    property MonthlySchedule: TMonthlySchedule read FMonthlySchedule implements IJclMonthlySchedule;
    property YearlySchedule: TYearlySchedule read FYearlySchedule implements IJclYearlySchedule;

et chacune des interfaces implémentées possède une propriété Interval

quand j'essaye d'imaginer cette classe sans les implements
dans ce cas apparement implementer toutes ces interfaces directement dans la classe TSchedule aurait compliqué l'écriture de la propriété Interval dans TSchedule (elle est alors nécessaire pour implementer le contrat des interfaces)

et l'accesseur GetInterval, qui aurait du alors contenir un "case" et une implémentation différente en fonction de l'aspect monthly, daily ou weekly .. du TSchedule
n'aurait servi à rien d'autre qu'a remplir les contrats d'interface de TSchedule
car Interval n'est de toute manière utilisée dans la classe en interne que directement via les objets objets contenus : MonthlySchedule, DailySchedule, WeeklySchedule

Dans ce cas, aussi, avec implements, l'interet est aussi que TSchedule peut switcher directement et automatiquement vers la bonne classe d'implémentation en fonction de l'interface utilisée...

...donc avec cet aspect ca rejoint effectivement dans un sens l'exemple des versions de directX : implementer différents concepts similaires dans une classe (mais ayant une implémentation différente)
afin de pouvoir switcher de l'un à l'autre en fonction de l'interface utilisée.

Code :

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

1
2
3
4
5
6
7
8
 
TVersionManager = class(TInterfacedObject,IVersion1,IVersion2,IVersion3)
  //.... 
  property Version1:IVersion1 read GetVersion1 implements IVersion1;
  property Version2:IVersion2 read GetVersion2 implements IVersion2;
  property Version3:IVersion2 read GetVersion3 implements IVersion3;
  //...
end;

finalement, IJclDailySchedule, IJclWeeklySchedule, IJclMonthlySchedule...
sont elles aussi différentes versions d'une même mécanique de base.

[DenDemble]

je vais essayer de créer mon TAggregatableObject avec implements !

je n'y avait pas pensé mais ça m'a l'air d'être un cas tout indiqué...
après tout TInterfacedObject et TAggregatedObject sont 2 versions d'une même mécanique qui met en oeuvre le ref counting et queryinterface..

[Kaféine]

Dans ce Tschedule, effectivement la property en commun pourrait justifier l'usage d'implements. mais je ne vois que ca personnellement.