Zur Laufzeit erzeugte Klassen mit Parametern versorgen

[stahli]

Zitat von Jumpy:

Und dann noch eine Frage zu Fabriken (da ich durch die ganzen "verweiste Referenzen"-Threads der letzten Zeit etwas verwirrt bin). Eine Fabrik erzeugt ein Objekt und "gibt dass nach aussen an eine andere Klasse weiter" (Wenn man so will an den Kunden der Fabrik). Jetzt gibt es doch 2 Referenzen auf das Objekt. Wer gibt das Objekt später wieder frei und wie erfährt der andere davon?

Ich denke mal, dass Du Dich hierauf beziehst:
- http://www.delphipraxis.net/166899-i...eferenzen.html
- http://www.delphipraxis.net/159095-r...e-objekte.html

Grundsätzlich sehe ich mehrere Möglichkeiten:

1) Du verwaltest keine festen Referenzen auf ein bestimmtes Objekt, sondern nur eine Id. Bei Bedarf forderst Du bei einem "Broker" anhand der ID das entsprechende Objekt ab und bekommst dieses oder nil geliefert. In deiner aktuellen Methode kannst Du dann mit dem Rückgabewert arbeiten.
Der "Broker" kann dann die Objekte eine bestimmte Zeit zwischenspeichern und irgendwann wieder verwerfen.
Die Objekte müssen sich also nicht dauerhaft im Speicher befinden sondern können bei Bedarf neu erzeugt und mit Daten aus einer Datenbank "befüllt" werden (ORM).
Da Du keine festen Referenzen verwaltest, brauchst Du auch keine Referenzen auf nil setzen, wenn Du ein Objekt auflöst.

2) Eine etwas halbherzigere Lösung wäre, alle erzeugten Objekte (einer bestimmten Sorte) in einer Liste zu speichern und beim Auflösen wieder daraus zu entfernen. Dann kann man bei jedem Zugriff auf eine Objektreferenz prüfen, ob sich das Objekt noch in der "Gültigkeitsliste" befindet. Statt Assign(o) könnte man sich eine Funktion Exist(o) deklarieren.

3) Wenn Du mit reinen Objekten arbeitest und diese gegenseitig referenzierst, dann kannst Du mit einem Observer-Pattern referenzierende Objekte bei referenzierten Objekten anmelden (in einer Liste eintragen). Wird das referenzierte Objekt aufgelöst, werden alle referenzierenden Objekte zuvor darüber unterrichtet und setzen die entsprechende Eigenschaft auf nil. Das muss man jedoch alles von Hand regeln und dafür entsprechende Listen und Methoden einführen.

4) Anstatt Objekte kann man Interfaces verwenden, welche einige Vorteile haben allerdings auch einigen Mehraufwand mit sich bringen. Interfaces werden sozusagen automatisch überwacht und wenn kein Interface auf ein Objekt mehr verwendet wird, wird das Objekt freigegeben (jedenfalls in Delphi).

EDIT: Ach so, und die Lösung von Thom unter dem ersten Link, die die Ansätze 3 + 4 miteinander verbindet.