Delphi-PRAXiS
Seite 3 von 5     123 45      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Tutorials und Kurse (https://www.delphipraxis.net/36-tutorials-und-kurse/)
-   -   Delphi Klassen in Delphi (https://www.delphipraxis.net/16557-klassen-delphi.html)

GuenterS 5. Jul 2005 20:06

Re: Klassen in Delphi
 
Zitat:

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 5. Jul 2005 23:00

Re: Klassen in Delphi
 
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 6. Jul 2005 07:46

Re: Klassen in Delphi
 
Zitat:

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:

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 6. Jul 2005 22:53

Re: Klassen in Delphi
 
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 7. Jul 2005 07:48

Re: Klassen in Delphi
 
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 29. Okt 2005 07:32

Re: Klassen in Delphi
 
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 29. Okt 2005 09:49

Re: Klassen in Delphi
 
[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.

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

jbg 29. Okt 2005 10:06

Re: Klassen in Delphi
 
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 29. Okt 2005 14:07

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

Luckie 6. Mai 2006 01:52

Re: Klassen in Delphi
 
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 15:19 Uhr.
Seite 3 von 5     123 45      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz