Instanz sich selber zerstören lassen?

[OLLI_T]

Hallo Minz!

Hab gerade mein Festplatte abgekehrt und dachte bevor ich´s in den gelben Sack stecke ...

Gegenfrage: Konstruiere doch bitte mal ein praktisches Beispiel, wann es sinnvoll ist, dass sich die Instanz einer Klasse selber freigibt? Woher weiss der Programmcode drumherum, dass diese Klasse sich ins Nirwana verabschiedet hat?

Gruss

OLLI

[SirThornberry]

@mr2: stimmt, das wörtschen "class" hab ich übersehen. Aber wie macht ich das dann mit der selbstzerstörung wenn ich immer TComponent.methode aufrufen muss? also:

Delphi-Quellcode:

myirgendwas := TIrgenwas.create;
[...]
myirgendwas.machwas; //vermutlich so nicht da ich ja in dem fall wieder das ganze als methode der instanz aufrufe
[...]
Tirgenwas.machwas; //so vermutlich auch nicht weil ja jetzt nicht bestimmt ist welche instanz zerstört werden soll

[Minz]

@Olli
1. Selbstorganisierende Prozesse
2. Weil eine Instanz sich selber zerstört heißt das nicht, dass die Hauptanwendung, nichts davon mitbekommt. Nur liegt die Kontrolle der Selbstzerstörung nicht bei der Hauptanwendung, dass ist der Unterschied.

[choose]

Zitat:

Zitat von Minz

Weil eine Instanz sich selber zerstört heißt das nicht, dass die Hauptanwendung, nichts davon mitbekommt. Nur liegt die Kontrolle der Selbstzerstörung nicht bei der Hauptanwendung [...]

Hallo Minz,
wie stellst Du sicher, dass niemals Referenzen auf das Objekt gehalten werden, bzw. wirklich alle Referenzen aufgehoben werden, wenn die "Hauptanwendung benachrichtigt wird"?

Darüber hinaus macht es keinen Unterschied, ob die "von außen"

Delphi-Quellcode:

AnObject.Free;

oder "von innen"

Delphi-Quellcode:

Self.Free

aufrufst, sofern anschließend nicht mit dieser Referenz arbeitest.
Letzteres ist kritisch, wenn Du mit der StdImplementierung von Delphis Interfaces arbeitest oder Du nicht hundertprozentig sicherstellen kannst, das nicht irgendwo (zB in Listen von Komponenten) noch auf das Objekt referenziert wird.

Eine oft elegantere Methode besteht darin, so lange eine Referenz auf das Objekt zu halten, bis es den Abschluss seiner Arbeit dem Klienten meldet und dieser seine Referenz freigibt. Sollte dies der letzte Verweis auf das Objekt gewesen sein, wird es freigegeben.

[Minz]

:wiejetzt: ist es für Euch ein Problem sicherzustellen, dass keine Referenzen mehr auf ein Objekt existieren?

Ich jedenfalls weiß, wie mein Code funktionieren soll, und an welcher Stelle Referenzen sind.

Wäre mir lieber Ihr sagt mehr zu der Eingangsfrage als die Sinnfrage zu diskutieren.

Und unter Umständen kann es doch einen Sinn machen wer die Kontrolle über die Zerstörung hat.

[maximov]

Die eingangsfrage wurde doch mit 'Self.Free;' befriedigt...da bleibt ja nur noch die sinnfrage :-D

Wenn sich das object zB. in einer hierarchie befinden würde, dann is es durchaus sinnvoll! Das object erkennt, dass es nicht länger benötigt wird und zerstört sich. Im destruktor nabelt es sich vom parent ab und benachrichtigt die notifier etc., um dann selbstmord zu begehen 8) ..nur als beispiel.

cu.
maximov.

[Minz]

Naja aber der Sir Thornberry hatte einen Einwand

Worauf mr2 mit class procedure ankam

und des hatten wir noch nicht ganz geblickt mit dem class.

Wenn jetzt einer kommt und sagt, braucht man nicht, und ich sicher sein kann, dass das Objekt dann korrekt geselbstmordet ist, dann ist alles ok :mrgreen:

achso @maximov an sich habe ich nichts gegen sinnfragen, wenn man dahinter raushört: "ich habe interesse" und nicht "das ist schwachsinn".

es ist ein für mich ein Unterschied ob jemand danach sagt "siehst du hab ichs doch gesagt" oder "sogesehen ist es nicht sinnvoll". Nur vorher von etwas sinnlosem auszugehen ohne die Hintergründe zu kennen oder weil man sich nichts vorstellen kann blabla :wall:

[maximov]

Is scho recht :dance: Ich zu mindest finde objekt-suizid in einigen fällen sehr sinnvoll! Und dass mit class ist IMAO blödsinn, da ja keine referenz existiert, die sich selbst morden könnte :spin2:

cu.