Klassen in Delphi

[Luckie]

Klassen in Delphi
Thema: Einführung in die objektorientierte Programmierung mit Delphi
Datum: 2007-12-02

Das Tutorial wurde - im Zuge der Vereinheitlichung der Layouts meiner PDF-Dokumente - noch mal neu mit Latex geschrieben. Inhaltlich hat sich nichts geändert. Das Layout ist jetzt doppelseitig und kann so schön ausgedruckt und gebunden werden (falls das jemand machen sollte ).

Das Tutorial liegt als PDF vor und kann hier: http://delphitutorials.michael-puff.de runtergeladen bzw. online eingesehen werden. In dem dazugehörigen Zip Archiv (Klassen_in_Delphi.zip) befinden sich noch zusätzlich Demos.

2007-12-02:
Kapitel "Sichtbarkeiten" ünberarbeitet.
Anhang mit Interans zum Konstruktor, Destruktor und Methodenzeigern von Andreas Hausladen.

[GuenterS]

Zitat von negaH:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject); 
...
    TRectangle(Figure).Show('TFigure.Create / TRectangle(Figure).Draw'); 
...

Ich habe das Tut nicht gelesen, gebe aber Sakura absolut Recht. Dieses Beispiel ist ein absolutes Negativbeispiel wie man es auf garkeinen Fall machen sollte. Es könnte aber als Eingangs-Beispiel für die Vermeidung von harten TypCast bei Klassen dienen. Denn so wie nachfolgend wäre der TypCast OOP konform richtiger gewesen:

Delphi-Quellcode:

 (Figure as TRectangle).Show;

Dieser Typcast würde dann eine Exception zu Laufzeit erzeugen, das TFigure NICHT von TRectangle abgeleitet wurde, und somit auf diesen offensichtlichen Programmierfehler hinweisen.

Gruß Hagen

Übrigens TFigure ist auch nicht von TRectangle abgeleitet, sondern umgekehrt :grins:

Und die Exception gibts in dem Fall hoffentlich nur wenn es sich um statische Bindung handelt, bei dynamischer bzw. virtueller Bindung erwart ich mir, dass ich da keine bekomme...

Und wie wärs mit...

Delphi-Quellcode:

if (Figure is TRectangle) then
   TRectangle(Figure).Show;

Da würdest schon zur Compiletime merken, wenn TRectangle nicht von TFigure abgeleitet ist.

[negaH]

Zitat:

Da würdest schon zur Compiletime merken, wenn TRectangle nicht von TFigure abgeleitet ist.

Nein würdest du nicht merken Denn das Ziel war es die Methode .Show; aufzurufen von einer Klasse die garkeine solche Methode implementiert. Und das sollte UNMÖGLICH sein, tja wenn da nicht der harte TypCast wäre der die Typsicherheit des Compilers ausschaltet. Das Ziel war es eben NICHT dynamisch zur Laufzeit auf nicht vorhersagebare Umweltbedingungen, sprich dynamisch allozierte Klassenobjekte zu reagieren. In dem besagtem Beispiel war schon im Source die zu verwendende Klasse fixiert, ergo ist der "as" Operator das probatest Mittel um "falsche" Typcast durch "schusselige" Programmierungen zu verhindern.

Der "is" Operator im Zusammenhang mit der IF THEN Abfrage ist keine Typüberprüfung die zur Compiletime durch den Compiler durchgeführt wird. Die "is" und "as" Operatoren sind ausschließlich Laufzeitüberprüfungen.

Gruß Hagen

[GuenterS]

Zitat von negaH:

Der "is" Operator im Zusammenhang mit der IF THEN Abfrage ist keine Typüberprüfung die zur Compiletime durch den Compiler durchgeführt wird. Die "is" und "as" Operatoren sind ausschließlich Laufzeitüberprüfungen.

:grübel:

Laut Hilfe in Delphi...

Zitat von Delphi Hilfe:

Der Operator is führt eine dynamische Typprüfung durch. Mit ihm können Sie den aktuellen Laufzeittyp eines Objekts ermitteln. Der Ausdruck

Objekt is Klasse

gibt True zurück, wenn Objekt eine Instanz der angegebenen Klasse oder eines ihrer Nachkommen ist. Trifft dies nicht zu, wird False zurückgegeben (hat Objekt den Wert nil, ist der Rückgabewert ebenfalls False). Wenn der deklarierte Typ von Objekt nicht in Beziehung zu Klasse steht (wenn die Typen also unterschiedlich und nicht voneinander abgeleitet sind), gibt der Compiler eine Fehlermeldung aus. Ein Beispiel:

if ActiveControl is TEdit then TEdit(ActiveControl).SelectAll;

Diese Anweisung prüft zuerst, ob die Variable eine Instanz von TEdit oder einem ihrer Nachkommen ist, und führt anschließend eine Typumwandlung in TEdit durch.

Dann scheint die Fehlerhaft zu sein, denn wenn der Compiler es merkt, dann ist das zur Compilezeit, zur Laufzeit selber hat der Compiler nichts mehr am Programm zu tun.

[negaH]

Zitat:

dynamische Typprüfung durch. Mit ihm können Sie den aktuellen Laufzeittyp eines Objekts ermitteln.

was sagt die Delphi Hilfe ?

dynamische Typprüfung, also keine statische zur Compiletime.
aktuellen Laufzeittyp eines Objekts, da steht es doch Laufzeit

Wenn es so wäre wie du es meinst so müsste:
1.) die if then Abfrage ja sinnloser Code sein
2.) der Compiler beim kompilieren des Programmes schon einen Fehler bringen, tut er das ?

Gruß Hagen

[GuenterS]

Zitat:

Der Ausdruck

Objekt is Klasse

gibt True zurück, wenn Objekt eine Instanz der angegebenen Klasse oder eines ihrer Nachkommen ist. Trifft dies nicht zu, wird False zurückgegeben (hat Objekt den Wert nil, ist der Rückgabewert ebenfalls False). Wenn der deklarierte Typ von Objekt nicht in Beziehung zu Klasse steht (wenn die Typen also unterschiedlich und nicht voneinander abgeleitet sind), gibt der Compiler eine Fehlermeldung aus.

Um mal die (unrevelanten) Aussagen der Delphi- Hilfe wegzulassen...

Da steht geschrieben, dass der Compiler dies tut, da denke ich schon irgendwie, dass es eben nicht (nur) zur Laufzeit passiert.

Der "If then" Konstrukt macht schon Sinn, er prüft ja nicht nur zur CompileZeit (ganz grobe Fälle ab) sondern auch zur Laufzeit.

[Luckie]

Es gibt eine neue Version des PDF dieses Tutorials. Dank OpenOffice 2.0 jetzt mit Lesezeichen für die Kapitel. Alles weiter im ersten Posting: http://www.delphipraxis.net/internal...ct.php?t=18769

[jbg]

[quote="GuenterS"]

Zitat:

er prüft ja nicht nur zur CompileZeit (ganz grobe Fälle ab) sondern auch zur Laufzeit.

Und diese "ganz groben Fälle" sind wenn du eine Instanz mit einer der Klasse aus einer ganz anderen Vererbungshierarchie prüfst.

if Firgure is TStringList then // hier meckert der Compiler weil TStringList nicht in der gesamten Vererbungshierarchie von TFigure vorkommt.

[jbg]

Wenns auch nur ein marginaler Fehler ist, aber diese Warnung hast du wohl abgetippt und dabei das "O" von TObject kleingeschrieben:

Zitat:

[Warnung] Unit1.pas(20): Methode 'Destroy' verbirgt virtuelle Methode vom Basistyp 'Tobject'

Die Groß- und Kleinschreibung von Bezeichnern ändert sich in den Code-Beispielen.

Zitat:

(MyFruit as TcitrusFruit).Squeeze

Zitat:

Dynamische Methoden sollten nur verwendet werden, wenn sich dadurch ein nachweisbarer Nutzen
ergibt. allgemein sollte man virtuelle Methoden verwenden.

Die VCL nutzt dynamic Methoden (zusätzlich) immer dann, wenn sie von einer Benutzer-Interaktion aufgerufen werden wie z.B. KeyDown, KeyUp, KeyPress, Click, DblClick, MouseDown, MouseUp, MouseMove, ...

[Luckie]

Danke für die Hinweise. Wenn es ein Update gibt, werde ich das (hoffentlich) berücksichtigen. Jetzt lasse ich es erstmal so.

[Luckie]

Das PDF wurde neu erzeugt. Die Seitenzahlen im Inhaltsverzeichnis sind jetzt Links und die Kapitel im Adobe Acrobate Reader werden als Bookmarks angezeigt.

Downmloadlink im ersten Beitrag.