liege ich richtig mit dem OOP-Versuch

[EdAdvokat]

Danke habe den Fehler gefunden und es läuft. Zusammengefaßt: ich muss ich nicht unbedingt auf Methoden zugreifen, sondern kann
mit den propertys operieren; sie aufrufen bzw. ihnen Werte zuweisen und damit rechnen...Güligkeitsprüfungen vornehmen usw. Somit
können sie mit privat oder gar mit strict privat versteckt werden, um sie vor fremden Zugriff zu schützen.
Damit bin ich einen großen Schritt vorangekommen.
Die Problematik Destructor Destroy habe ich studiert und werde so wie von euch empfohlen verfahren, wenngleich ich neben dem bereits
zitierten Tutorial auch noch meinen Lieblingsautorenkoll. Michael Ebner und Christoph Klawun in GoTo Pascal mit Delphi 4 S. 398 zitieren
möchte: "Von TObject erben alle Objeke den Konstruktor Create sowie die Destruktoren Destroy und Free. (Der Destruktor Free untersucht zunächst,
ob überhaupt eine Instanz von dem Objekt erstellt wurde und ruft dann gegebenfalls Destroy auf. Im Zweifelsfall sollten Sie stets Free
verwenden.)
Doberenz und Kowalski in Borland Delphi 7 S 565 beschreiben die Destruktoren so wie ihr hier im Forum mit dem Aufruf von inherited Destroy.
Es gibt also durchaus unterschiedliche Betrachtungsweisen. Ich möchte keinesfalls eine Konstruktor/Destrukor-Diskussion befeuern. Ich
werde so verfahren wie hier empfohlen. Nochmals Danke für die Hinweise

[SProske]

Wenn wir bezüglich der Destruktoren mal in die Vorfahrenklasse TObject schauen, sieht das folgendermaßen aus:

Delphi-Quellcode:

  TObject = class
    procedure Free;
    destructor Destroy; virtual;

...

procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

destructor TObject.Destroy;
begin
end;

Free ist also eine Methode, kein Destructor. Korrekt ist, dass man (so gut wie) immer .Free aufrufen sollte und nicht .Destroy Destroy ist als virtual deklariert und ist üblicherweise das, was man in seiner abgeleiteten Klasse (sofern nötig) überschreiben kann (wichtig: nicht das override vergessen!)

[Der schöne Günther]

Ich hoffe ich entführe das Thema nicht zum Schluss noch, aber die Properties würde ich persönlich nicht überbewerten - Das nur als Ratschlag von mir. So wie sie in Delphi geschaffen sind sehe ich nicht, was man durch sie gewinnt. Andere Sprachen kommen auch super ohne Properties aus.

Um ehrlich zu sein sehe ich nur Nachteile:

• Eine Variable kann ich per Referenz übergeben. Das erlaubt Dinge wie Inc(zähler); statt zähler := zähler + 1; . Mit Properties geht das nicht.
• Bei Properties sehe ich in der Code-Vervollständigung nicht ob ich sie auch beschreiben darf. Erst wenn es beim Kompilieren einen Fehler gibt.
• Im Endeffekt nur zusätzlicher Tippaufwand.

[EdAdvokat]

nun doch "constructor/destroctor": Ich habe weitere Autoren befragt: Hans-Georg Schumann in Delphi für Kids spricht sich auf S 387 für free aus:
"Es könnte ja sein, dass beim Erzeugen eines Objekts ein Fehler auftritt. Und gerade die Methode Free sorgt dafür, dass auch ein nur zum Teil erzeugtes Objekt wieer ordnungsgemäß
freigegeben wird. Man sollte also zur Freigabe von Objekten nur Free benutzen.
Eigentlich könnten wir den von TObject geerbten Destrokor so übernehmen, wenn wir nicht auch ein paar eigene Aufräumungsarbeiten erledigen wollen. Dann könnte die Definition einer
eigenen Destroy-Methode zub. so aussehen:
destructor TMonster.Destroy;
begin
Form1.label....
Form1.label...
inherited Destroy;..
end;
Auf jeden Fall sollte zum Schluss der geerbte Destruktor aufgerufen werden. Die Muttermethode Free ruft nun den Destruktor auf - wenn er mit override gekennzeichnet wurde.
Dabei kommt (ganz am Ende) auch der Destruktor der Mutter zum Einsatz."

Autorenkoll. Delphi 3 im Team: S 135 ff wie gehabt

constructor create(AOwner: TComponent); override;
destructor Destroy; override;

...die Methode Free der Klasse T... dient dabei der nötigen Freigabe des Speichers. Auch hier rufen wir wieder den Destruktor der Elternklasse auf.

Bohne/Lang in GoTo Delphi 4 S 282: " Hier wir für jede Kompnente der Destruktor Destroy aufgerufen, der den von der Komponente werdendeten Speicher freigigt. Normalerweise
sollte Destroy nicht direkt aufgerufen werden, satt dessen sollte die sichere Funktion Free aufgerufen werden, die selbst Destroy aufruft...."

Elmar Warken in Delphi 4 S. 193 ff meint..."Empfehlenswerter ist es jedoch statt dessen die Methode Free aufzurufen...."

So nun genug Literatur. Es gibt also durchaus unterschiedliche Herangehensweisen, die alle nicht falsch sein müssen. Die einen sind gründlicher doch auch die anderen kommen
zum Ziel.
Sollte sich jemand finden, das Tutorial zu überarbeiten, könnte ggf. auf diese Literatur zurückgegriffen werden.

[Jumpy]

Nur mal zur Klarstellung:

Wenn du in deiner Klasse einen eigenen Destruktor brauchst, weil Klassenspezifische Dinge "abgeräumt" werden müssen, dann überschreibe die Methode / den Destructor "Destroy".
Das ist das eine!


Wenn du eine Klasse erzeugt und damit was gemacht hast, dann musst du sie am Ende wieder frei geben. Da sollte dann die (von TObject durchgeerbte) Methode "Free" aufgerufen werden (und nicht selber Destroy aufrufen!). Die Methode Free ruft dann intern (dein) Destroy auf und wenn in deiner Destroy-Methode ein inherited steht (was so sein sollte), dann auch das Destroy der Vorfahren Klasse.
Das ist das andere!

Nichts anderes steht letztlich in den von dir genannten Zitaten.

[TBx]

Wie ich bereits geschrieben habe, ist die Überarbeitung des Tutorials auf meiner ToDo-Liste.

Zusammenfassend kann man sagen, dass man Objekte über .Free freigeben sollte.
Leitet man eine Klasse ab, so ist der Destructor .Destroy zu überschreiben, wenn bei der Zerstörung des Objektes weitere Aufräumarbeiten notwendig sind. Wie schon genannt wurde, ist der Destructor mit destructor Destroy; override; zu überschreiben, da sonst die Polymorphie untergraben würde und dadurch das von TObject geerbte Free nicht den korrekten Destructor aufrufen würde.
Eine ganz schlechte Idee ist es, das Free neu zu implementieren. Überschreiben kann man es nicht, da es in der Basisklasse nicht virtual ist. Aufräumarbeiten gehören per Definition in den Destructor. Free ist nur eine Methode, die nicht jeder nutzen muss. Es ist durchaus legitim, Destroy aufzurufen, wenn man sicher ist, dass es das Objekt noch gibt. Hat man nun die Aufräumarbeiten in einem überdeckenden procedure Free; reintroduce; implementiert, werden diese nicht ausgeführt.
Etwas anderes sagen die zitierten Autoren nicht.
Eine Aussage ist allerdings unsinnig, Free kann nicht vollständig erzeugte Objekte nicht besser oder schlechter freigeben als Destroy . Die Methode Free prüft nur, ob die Variable, über die die Methode aufgerufen wird auf eine gültige Instanz von TObject weist und ruft dann Destroy auf.

[EdAdvokat]

nur zur Vollständigkeit das kleine Testprog. Flaecheninhalt gemäß den Ratschlägen. Nochmals Danke für die Unterstützung

[TBx]

So, ich habe die irritierende Benamselung des Destruktors im Tutorial korrigiert.

[Luckie]

Kurz. Den Destructor muss man nur überschreiben, wenn man selber in der Klasse Objekte erstellt, die freigegeben werden müssen. Und dann ruft man ganz zu Anfang im Code vom Destructor inherited auf, um den Destructor der Elternklasse aufzurufen und dann gibt man seinen Kram frei.

[TBx]

Hier muss ich Dir widersprechen. Es geht nicht nur um weitere Objekte, die freigegeben werden müssen, sondern um alle Arbeiten, die bei Zerstörung des Objektes ausgeführt werden müssen. Und im Destructor wird das inherited als Letztes aufgerufen.