Moin Rabenrecht,
ich würde diese Vorgehensweise nicht nur auf Objekte einschränken,
sondern auf alle Arten von Resourcen ausdehnen.
Um sicher zu gehen, dass man nichts vergisst wieder freizugeben,
sollte man, wenn man eine Resource belegt, auch gleich deren
Freigabe an der Richtigen Stelle unterbringen.
Meist gibt einem die Sprache hierfür schon die entsprechenden
Strukturen schon an die Hand.
Beispiele:
Eine
Unit kann einen initialization und einen finalization
Abschnitt haben.
Eine Resource, die innerhalb der
Unit (damit, ggf., innerhalb des
Programms zur Verfügung stehen soll) wird im initialization
Abschnitt belegt. Wenn man dann gleich im finalization-Abschnitt
die Freigabe einträgt kann man das später nicht vergessen.
Bei Klassen wären das dann constructor und destructor.
Innerhalb einer Methode/Funktion/Prozedur wird man häufig
die Try/Finally-Blöcke verwenden.
Delphi-Quellcode:
Resource belegen
try
mit der Resource arbeiten
finally
resource freigeben
end;
Da es wichtig ist hier nicht die Übersicht zu verlieren,
sollte man auch nie ein Objekt als Rückgabewert einer
Methode verwenden, wenn dieses erst dort erzeugt wird,
ausser die Klasse aus der die Methode stammt verwaltet
die Objekte selber (z.B. TListView.AddItem)
An welchen Stellen man Resourcen belegt und wieder freigibt
mache ich davon abhängig, wie und wie oft diese jeweils
benötigt werden.
Wenn ich, z.B., in den Methoden eines Formulares häufig eine
TStringList benötige kann es sinnvoll sein diese als Feld des
Formulares zu deklarieren und dann jeweils zu leeren statt
sie immer wieder neu zu erzeugen und freizugeben.
sinnvoll sein, diese