Discussion :

[Bruno75]

J'ai un objet(Objet1) qui contient une référence vers un autre objet(Objet2 pour faire simple) et qui est responsable de sa création/destruction. Cependant, il peut fournir la référence "à l'extérieur".

autant je peux rendre private les constructor et destructor de la classe de Objet2 et ainsi fournir une interface public clean, autant si Objet2 est typecast en TObject et Free est utilisée je l'ai dans l'os.

avant de rajouter un moyen dans la classe de vérifier si l'appel à destroy est valide où pas ( par exemple mettre une variable private qui ne pourrait être accédée que par l'objet responsable du cycle de vie, par exemple une référence à Objet1 qui serait mise à nil au moment de l'appel à Free par Objet1 justement et de tester dans destroy si Reference == nil), je me demandais si y avait un moyen autre qui m'aurait échappé.

et la méthode entre paranthèse a l'inconvénient d'être une méthode dynamique. alors qu'elle serait là pour prévenir une erreur statique, c a d un appel d'une méthode que le programmeur n'aurait pas du faire.

[Andnotor]

autant je peux rendre private les constructor et destructor de la classe de Objet2

Non, ce n'est pas possible. Tu ne peux pas diminuer la visibilité d'une méthode.

Le seul moyen est de ne pas donner directement accès à Object2 et d'encapsuler les appels à certaines procédures intéressantes dans des méthodes de Object1.

[tourlourou]

au lieu de fournir une référence à l'objet, ne devrait-il pas fournir simplement une interface, qui n'implémenterait pas de destructeur ?

[Bruno75]

oui. je disais simplement je pouvais empêcher Object2.destroy et Object2.Free et TClass2.Create mais pas TObject(Objet2).Free et je suis d'accord pas TObject(Objet2).destroy

pour ce qui est de l'interface, oui à condition d'implémenter les fonctions QueryInterface et le tralala ou dériver d'une classe qui les implémente (ce qui n'est pas toujorus possible vu qu'on peut pas faire de dérivations multiples). donc c pas mal

mais je me demandais si y avait d'autres truc plus léger. en fait je me demandais si j'avais raté un truc dans le langage. ou qqch dans le genre.

[Paul TOTH]

oui. je disais simplement je pouvais empêcher Object2.destroy et Object2.Free et TClass2.Create mais pas TObject(Objet2).Free et je suis d'accord pas TObject(Objet2).destroy

pour ce qui est de l'interface, oui à condition d'implémenter les fonctions QueryInterface et le tralala ou dériver d'une classe qui les implémente (ce qui n'est pas toujorus possible vu qu'on peut pas faire de dérivations multiples). donc c pas mal

mais je me demandais si y avait d'autres truc plus léger. en fait je me demandais si j'avais raté un truc dans le langage. ou qqch dans le genre.

C'est possible, à condition de faire appel à Mr Indestrutible

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
type
  TIndestructible = class(TObject)
  protected
    procedure BeforeDestruction; override;
  end;
 
procedure TIndestructible.BeforeDestruction;
begin
  Abort;
end;

Attention cependant, Abort est une exception silencieuse, donc un appel au destructeur ne détruit pas l'objet mais interrompt le code

exemple :

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
 
procedure TForm1.FormCreate(Sender: TObject);
var
  MrIndestructible : TIndestructible;
  Index : Integer;
begin
  FList := TList.Create;
  for Index := 0 to 100 do
  begin
    MrIndestructible := TIndestructible.Create;
    FList.Add(MrIndestructible);
    try
      MrIndestructible.Free;
    except
      // cause of Abort exception
    end;
  end;

[ShaiLeTroll]

Pourquoi ne pas gérer lors de l'accesseur, un flag qui indique que l'objet est affecté de l'extérieur ... lorsque Objet2 est interne, il est manipulé via le membre Privé (FObjet2) et en externe par la propriété Objet2 ...

Quel est l'ancêtre de TObjet2 ? le TComponent avec son Owner te premettrait d'oublier ces petits tracas ...

Ou fait une sorte de Register où tu indique à la Classe TObjet1 une liste d'objet à ne pas libérer ... (sorte de GarbageCollector à l'envers)

Ou encore tu mets une propriété Owned dans Objet2 qui indiquera si il est libéré par Objet1...

Ou encore tu ne pratique que par Clonage d'objet, ainsi les références sont idenpendantes (tu peux mettre en place un mecanisme qui maintient les données des instances clonées au même valeur ... jusqu'au moment où tu détache complètement un clone ...)

Ce Mr Indestrutible, c'est juste une grosse fuite mémoire ... mieux vaut passer par un mécanisme Notification avant la Libération ?

Tu pourrais repartir de la problématique d'origine, tu bloques l'analyse de ton problème à la libération interdite depuis l'extérieure ...

[Kaféine]

Salut,

Mr indestructible

il est jamais libéré. (bah oui il est indestructible !)

peut lui ajouter un état IsIndestructible commutable pour qu'il crève un jour au moins

[Paul TOTH]

Salut,

Mr indestructible

il est jamais libéré. (bah oui il est indestructible !)

peut lui ajouter un état IsIndestructible commutable pour qu'il crève un jour au moins

ah mais dans ce cas ce n'est pas le même composant ^^

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
 
type
  TAchile = class
  private
    FTalon : Boolean;
  protected
    procedure BeforeDestruction; override;
  public
    property Talon: Boolean read FTalon write FTalon;
  end;
 
procedure TAchile.BeforeDestruction;
begin
  if not FTalon then Abort;
  inherited;
end;

[Bruno75]

Ok je vois un peu mieux ou ca coince. en fait, ce qui me gêne c plus un problème de 1 comment faire comprendre (doc, code, etc.) comment est géré la vie d'un composant à qqn qui voudrait juste l'utiliser. 2 quand laisser ou ne pas laisser des manières de faire planter le code.

1
qd on récupère une interface, on sait qu'il suffit de la mettre à nil et c bon
qd je fais un create, soit je devrait faire un Free plus tard, soit je refile le bébé à qqn d'autre, par exemple une TObjectList.Create(True)
2
ex en Delphi, si je Free 2 fois le même objet ou si j'écrit nimporte comment dans des tableaux

donc dans mon cas la question serait est ce que
- je devrais mettre en place une interface ?
- gérer un appel intempestif à Free ?
- simplement mettre une ligne dans la doc ?
- plus ou moins faire apparaître un pattern connu ?

je précise peut être mon exemple (je rappelle que le but est plus d'expliciter ce dont je parlais, et pas de partir sur une discussion sur la conception de gestion d'événements)
- 1 table en base TBL_DATA
- 1 classe qui interface le code et la base et lance des événements. TDAL
- 1 collecteur d'événement (Objet1) qui permet stocker les événements pour les gérer après coup. asynchrone. TEventServer
- 1 vue qui est intéressée par les événements de données de la classe d'interface. TView

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
 
EventServer =  TEventServer.Create
Dal := TDal.Create
View := TView.Create
 
//TDal a 2 events OnNewRow et OnDelRow qui trigger 
// si l'insertion ou la deletion a eu lieu avec succès.
 
TDal.TCreate
    OnNewRow = EventServer.NewEvent
    //OnNewRow est l'objet2 dont je parlais
end
 
TView.TCreate
   Dal.OnNewRow.Register(View.UneMethodDeGestion)
end
 
// plus tard au moment d'une insertion
 
TDal.NewRow
   //Code d'insertion
   OnNewRow.Trigger(RowId)
end
 
TDal.Destroy
   OnNewRow.Free // ??????
end

bon c un mauvais exemple vu que d'une certaine manière on pourrait s'attendre à si ce n'est un Free au moins un Release. je vous laisse commenter, peut être le questionnement que j'ai correspond à un cas qui n'existe pas je sais pas. mais je me dit qu'est ce qui va faire que le programmeur ne va pas faire un OnNewRow.Free, dois-je le gérer ? si je met une fonction release je dois me debrouiller pour que Free = Release ?
etc .

[Paul TOTH]

ok, sauf si ton code est plus complexe, personnellement je n'utiliserais pas un objet

deux approches:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
// première approche, OnNewRecord: TNotifyEvent
TDal.TCreate
    OnNewRow = View.UneMethodDeGestion;
end
// rien à libérer
 
// seconde approche, associer un objet et une méthode dans le serveur d'events
EventServer.RegisterMethod(Dal, View.UneMethodeDeGestion);
// et pour libérer
EventServer.UnRegisterMethod(Dal, View.UneMethodeDeGestion);

le truc que je ne comprend pas dans ton exemple, c'est ce que vient faire le EventServer dans tout cela

[Bruno75]

je pense vaut mieux clore le sujet, je crois j'ai pas été suffisament clair dans mon propre questionnement. je vais prendre le temps de reréfléchir à tout ça et si besoin je referai une nouvelle discussion.

@PaulToth : je me suis interessé à 1 vue mais en fait y en a plusieurs qui s'interessent à l'événement OnNewRow. d'ou le fait que OnNewRow soit un objet et non une méthode.
et ensuite, je fait une file d'attente d'événements, je ne souhaite pas callback directement dans le code de la vue. d'où le server. qui permet une notification asynchrone.

[Kaféine]

TAchille et son talon

Haha humour quand tu nous tient!