Masquer la procedure TObject.Free ?

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.

Citation:

---

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.

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 ?

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.

Citation:

---

Envoyé par 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.

---

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

Code:

---

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:

---

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;

---

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 ...

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 :)

Citation:

---

Envoyé par 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 :)

---

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

Code:

---

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;

---

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:

---

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 .

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

deux approches:

Code:

---

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 :)

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.

TAchille et son talon :)

Haha humour quand tu nous tient!