Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?

[Zacherl]

Hallo zusammen,

ich habe eine Funktion, welche ein Objekt erstellt, welches im weiteren Verlauf für eine unbestimmte Zeit innerhalb eines zweiten Threads verwendet wird. Die Funktion liefert das Objekt zusätzlich als Rückgabewert an den aufrufenden Benutzer zurück, damit dieser bestimmte Informationen (die der Thread setzt) mitverfolgen und auch per Methodenaufruf z.B. die Verarbeitung abbrechen kann.

Das Problem besteht nun in der Frage, wer das Objekt wieder freigeben soll. Geschieht dies nach seiner Verarbeitung im Thread, kann es sein, dass der Benutzer nachträglich versucht auf das nicht mehr existierende Objekt zuzugreifen. Gibt der Benutzer das Objekt frei, hat man das selbe Problem in umgekehrter Richtung.

Folgende Möglichkeiten sind mir eingefallen:

• :arrow: Ich gebe ein Interface zurück, welches von Delphi automatisch über _Release() freigegeben wird, sobald keine Referenz mehr existiert
• :arrow: Ich gebe in der Funktion ein Wrapper Objekt zurück, welches nach Art des Proxy Patterns auf das eigentliche Datenobjekt zugreift. Der Thread würde dann bei Freigabe des Datenobjekts auch ein Flag im Wrapper Objekt setzen, was dafür sorgt, dass der Benutzer nicht mehr auf bestimmte Werte und Methoden zugreifen kann

Welche dieser Methoden würdet ihr bevorzugen oder fällt euch vielleicht noch eine bessere Alternative ein?

Viele Grüße
Zacherl

[DeddyH]

Ist es denn unbedingt notwendig, dass die Funktion das Objekt erstellt? Ich tendiere eigentlich immer dazu, das Objekt außerhalb zu erstellen und dann als Parameter an die Routine zu übergeben, damit stellt sich das Problem erst gar nicht.

[Blup]

Interface deckt den Fall optimal ab, warum dann etwas neues erfinden.

[Lemmy]

Guten Morgen,

Instanz außerhalb erstellen (wer erstellt gibt frei) oder Interface verwenden, was wegen der geringeren Kopplung der Teile aber wohl der bessere Ansatz wäre.

[Mikkey]

Dass die Funktion hier das Objekt erstellt und zurückgibt, hat mMn mit der Problematik nichts zu tun.

Denkbar sind für die Freigabe beide Varianten, bei der zweiten sehe ich nur einen einigermaßen unüberschaubaren Verwaltungsaufwand und das Problem, dem Benutzer das ulkige Verhalten des Programms zu erklären.

Also ganz klar 1. Variante: wenn zwei oder mehr Threads das Objekt verwenden, darf es erst freigegeben werden, wenn der letzte damit fertig ist.

[mentaltec]

TObject mit Ref-Counter versehen, in einer Class TObjList merken
das Destroy dect den Refcounter und greift erst, wenn Refcounter == 0

oder so ähnlich, mfg

[Zacherl]

Zitat:

Zitat von DeddyH (Beitrag 1225943)

Ist es denn unbedingt notwendig, dass die Funktion das Objekt erstellt? Ich tendiere eigentlich immer dazu, das Objekt außerhalb zu erstellen und dann als Parameter an die Routine zu übergeben, damit stellt sich das Problem erst gar nicht.

In meinem Falle schon, da das Objekt innerhalb eines Threads verarbeitet wird. Ich kann die Instanz also nicht direkt nach Funktionsaufruf wieder freigeben.

Dann werde ich es mal mit der Interface Methode probieren. Dachte mir schon, dass dies die einfachste Lösung ist.

Danke an alle!

[Furtbichler]

Zitat:

Zitat von Zacherl (Beitrag 1226022)

In meinem Falle schon, da das Objekt innerhalb eines Threads verarbeitet wird. Ich kann die Instanz also nicht direkt nach Funktionsaufruf wieder freigeben.

Sollst Du ja nicht
Entweder ...
a)... die Architektur leicht abändern, um dem Paradigma: "Wer Dreck macht, räumt auch auf" gerecht zu werden, oder
b)... das Objekt einfach als Letztes im "Execute" freigeben oder
c)... das Objekt vom Threadersteller freigeben, sobald der Thread 'Fertig' meldet oder
d)... das Objekt gar nicht bzw. zum Programmende freigeben (wenn das sinnvoll ist)

Ich persönlich würde a) prüfen und wenn das nicht passt, c) umsetzen, da dann die Freigabe im Context des Objekterstellers geschieht.

[Zacherl]

Das ist alles leider nicht optimal. Ich versuche mal mein Problem etwas detaillierter darzustellen:
Ich habe einen Thread, welcher permanent von Programmstart bis zum Programmende läuft. Der Thread wartet im Hintergrund darauf, bis er einen oder mehrere Tasks zugewiesen bekommt und arbeitet diese dann ab. Die Tasks habe ich in einer Klasse gekapselt, welche einige Attribute wie z.b. den Progress und einige Methoden z.b. zum Abbrechen des Tasks besitzt.
Das Erstellen des Tasks passiert in der von mir genannten Funktion, welche das Objekt dann intern an den Thread weitergibt und zusätzlich dem aufrufenden Benutzer als Rückgabe liefert, damit man beispielsweise den Status des Tasks in einer Liste anzeigen lassen kann.

(a) scheidet für mich daher aus, weil ich nicht ohne Weiteres sagen kann, wer zuletzt auf das Objekt zugreift. Wenn ich es im Thread freigebe, könnte es sein, dass danach noch ein Zugriff von "außerhalb" erfolgt z.b. um die Daten in der Liste zu aktualiseren. Wenn ich es von Benutzerseite aus freigebe, könnte es passieren, dass der Thread noch nicht mit der Verarbeitung fertig ist.
(b) funktioniert in meinem Falle auch nicht, da der Thread ja zur kompletten Laufzeit des Programms aktiv ist
(d) hier würde mir recht schnell der Speicher vollaufen, da doch eine ganze Menge an Tasks verarbeitet werden

(c) würde funktionieren, allerdings ist das auch nicht wirklich "intuitiv" für den Anwender (Programmierer). Da müsste man in der Dokumentation ziemlich deutlich drauf hinweisen, dass die Freigabe des Objekts wirklich erst im entsprechenden Callback erfolgen darf und nicht direkt nach Funktionsaufruf.

Bin mir momentan unsicher, ob ich Methode (c) implementieren, oder es mit den Interfaces versuchen soll. Letztere haben allerdings auch gewisse Nachteile. Z.b. müsste ich dann auch in allen Callbacks das Interface anstelle des Objekts übergeben und auch hier in der Doku den Hinweis platzieren, dass die Instanz nur als Interface und nicht als konkretes Objekt gespeichert werden darf (weil sonst ja der Ref Counter Mechanismus nicht mehr greift), etc.

[Thom]

Zitat:

Zitat von Zacherl (Beitrag 1226100)

[...] dass die Instanz nur als Interface und nicht als konkretes Objekt gespeichert werden darf [...]

Das kannst Du recht effektiv verhindern, indem Du den Objektkonstruktor durch eine Klassenfunktion verdeckst:

Delphi-Quellcode:

class function Create: IMyInterface;
[...]

Damit bekommt niemand mehr Zugriff auf die eigentliche Objektinstanz (außer bei einem Cast

Delphi-Quellcode:

IInterface as TObject

) und damit den Destruktor.