Diskussion:Programmierkurs: Delphi: Pascal: Klassen

Verwendung von Free statt Destroy

Ich weiß, in meinem Handbuch steht das auch so drin, wie du das beschrieben hast, ARoth. Daran, dass Free zu keiner Exception führt, habe ich aber aus zwei Gründen erhebliche Zweifel:

- bei mir führt es immer zu einer Exception, wenn die Klasse noch nicht initialisiert wurde
- muss es auch, da Free eine Methode ist

Man kann auf Felder und Methoden einer Klasse nur zugreifen, wenn diese vorher initialisiert wurden (mit Ausnahme des Konstruktors, der diese Aufgabe übernimmt). Um auf Free zuzugreifen muss daher auch erst der Konstruktor der Klasse aufgerufen worden sein.

Ich prüfe daher immer vorher selbst:

if variable <> nil then begin
  variable.Free;
  variable := nil;
end;

So habe ich nie Probleme.

Ich hab's mal im Buch so stehen lassen, weil's die gängige Lehrmeinung ist. Vielleicht kann mir auch jemand zeigen, was ich dabei falsch mache.
-- Dannys9 19:55, 16. Feb. 2007 (CET)

Ich kann jetzt meine obige Aussage (teilweise) revidieren. Bei einem Objekt, das den Wert nil hat, kann die Methode Free ohne Exception aufgerufen werden. Das setzt aber voraus, dass das Objekt vorher explizit mit nil initialisiert wurde. Folgender Code führt zu einer Exception:

procedure Test;
var obj: TObject;
begin
  obj.Free
end;

Lokale Variablen enthalten zu Beginn einer Routine oder Methode meisten Datenmüll, daher sollten sicherheitshalber alle Objekte mit obj := nil; initialisiert werden, wenn sie nicht definitiv mit einem Konstruktor erstellt werden. Auf globale Objekte trifft dies im Übrigen nicht zu, da diese automatisch den Wert nil haben. Ich habe dies im Kapitel "Konstruktoren und Destuktoren" untergebracht.

--Dannys9 20:34, 11. Jul. 2007 (CEST)

Sichtbarkeiten

Hallo! Ich bin Delphi-Neuling und hatte mit den Sichtbarkeiten wie sie hier beschrieben sind, heftige Probleme. Habe mir mal folgende Zusammenfassung geschrieben:

strict private:		nur von Objekten der selben Klasse kann zugegriffen werden
			(damit Zugriff auch nur innerhalb einer Unit)
			Unterklassen erben diese Elemente aber können nicht darauf zugreifen

private:		nur der selben Unit aus kann zugegriffen werden
			nur Unterklassen der selben Unit können auf geerbte private-Elemente zugreifen


strict protected:	Unterklassen können auf geerbte strict-protected-Elemente zugreifen
			(egal in welcher Unit sie sind)
			auf Elemente von Objekten der (vererbenden) Klasse kann nicht zugegriffen werden

protected:		zusätlich zu strict protected:
			innerhalb der Unit kann auf Elemente von Objekten der (vererbenden) Klasse
			  von Unterklassen und fremden Klassen zugegriffen werden

Ist natürlich nur sehr knapp, aber vielleicht könnte man es so oder in ähnlicher Form im Wikibook unterbringen. Ich fand die bisherige (noch knappere) Beschreibung wie gesagt sehr verwirrend und es hat mich mehrere Stunden und eine Forendiskussion gekostet, bis ich es verstanden hab. -- 95.116.251.41 17:36, 26. Feb. 2012 (CET)