OS/2 Shareware BBS: 10 Tools

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / sibylft1.zip / DOC.DAT / DOC / OOP_REFG.INF (.txt) next >

Wrap

OS/2 Help File | 1996-04-14 | 72KB | 2,647 lines

ΓòÉΓòÉΓòÉ 1. OOP Referenz f╨ær SpeedSoft Sibyl Version 2.0 ΓòÉΓòÉΓòÉ This help is incomplete in this version ! It is only available in german for now ! Klassen Sichtbarkeit Instanzen Zuweisungen Felder Methoden Eigenschaften Metaklassen Vordefinierte Klassen Exceptions Vordefinierte Exceptions ΓòÉΓòÉΓòÉ 1.1. Klassen ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûä Klassen ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was sind Klassen? Die Basis der objektorientierten Programmierung ist der Begriff der Klasse. Ein Klasse ist ein strukturierter Datentyp, ╨öhnlich einem Record, jedoch weitaus m╨öchtiger. Ein Repr╨ösentant einer Klasse wird eine Instanz oder ein Objekt der Klasse genannt. Objekte sind dynamische Datentypen, die zur Laufzeit erzeugt und zerst╨ñrt werden. Eine Klasse legt den Bauplan f╨ær jede ihrer Instanzen fest. Die Deklaration einer neuen Klasse kann drei Arten von Komponenten aufweisen: Felder, Methoden und Eigenschaften. Zus╨ötzlich k╨ñnnen Klassen ╨æber den Mechanismus der Vererbung die Komponenten einer bestehenden Klasse ╨æbernehmen. Jeder Komponente einer Klasse kann individuell ein Typ von Sichtbarkeit zugeordnet werden. Dadurch wird festgelegt, wer die Komponente sehen und darauf zugreifen kann. Deklaration von Klassen Klassen werden auf die folgende Weise deklariert: <Syntaxdiagramm Classes> Klassen k╨ñnnen nur im ╨öu╤üersten G╨æltigkeitsbereich eines Moduls deklariert werden. Es ist nicht m╨ñglich, Klassen lokal in Prozeduren oder Funktionen zu deklarieren. Es ist ebenfalls nicht m╨ñglich, Klassen im Rahmen einer Variablen-Deklaration einzuf╨æhren. Es ist in Speed-Pascal ╨æblich, wenngleich nicht zwingend vorgeschrieben, da╤ü die Bezeichner von Klassen mit einem 'T' beginnen, um sie als Typbezeichner kenntlich zu machen. Komponenten einer Klasse Die Deklaration einer Klasse kann drei Arten von Komponenten aufweisen: Felder, Methoden und Eigenschaften. Felder sind Variablen innerhalb einer Klasse und werden auf die gleiche Weise deklariert und benutzt wie die Felder eines Records. Jedes Objekt einer Klasse verf╨ægt ╨æber einen kompletten eigenen Satz aller Felder der Klasse. Methoden sind Prozeduren oder Funktionen, deren Funktionalit╨öt eng mit der Klasse verkn╨æpft ist. Methoden werden ╨æblicherweise in Verbindung mit einer Instanz aufgerufen. Alle Instanzen einer Klasse teilen sich den gleichen Satz Methoden, so da╤ü deren Code nur einmal im Programm vorhanden ist. Eigenschaften stellen sich dem Benutzer einer Klasse ╨öhnlich wie Felder dar, bieten jedoch weitaus mehr M╨ñglichkeiten. Lesende und schreibende Zugriffe auf eine Eigenschaft k╨ñnnen sowohl auf ein Feld als auch auf eine Methode umgelenkt werden. Im letzteren Fall wird bei der Ausf╨æhrung einer Zuweisung implizit die zugrundeliegende Methode aufgerufen. Au╤üerdem k╨ñnnen die Zugriffsm╨ñglichkeiten einer Eigenschaft auf nur-Lesen oder nur-Schreiben eingeschr╨önkt werden. Vererbung Bei der Deklaration einer neuen Klasse kann eine bereits bestehende Klasse als Vorfahr angegeben werden, wodurch die neue Klasse automatisch ╨æber s╨ömtliche Komponenten des Vorfahren verf╨ægt, sofern es deren Sichtbarkeit zul╨ö╤üt. Zus╨ötzlich k╨ñnnen neue Komponenten deklariert oder vom Vorfahren geerbte Komponenten ╨æberschrieben werden. ╨¬berschreiben bedeutet, es wird f╨ær eine Komponente der neuen Klasse ein Bezeichner gew╨öhlt, der bereits im Vorfahren verwendet wird. Dadurch wird die ╨æberschriebene Komponente innerhalb der neuen Klasse verdeckt. Das ╨¬berschreiben hat aber keinen Einflu╤ü auf den Vorfahren selbst. Es k╨ñnnen nur Methoden und Eigenschaften ╨æberschrieben werden, nicht jedoch Felder. Beim ╨¬berschreiben von Methoden ist es wichtig, das Laufzeitverhalten der verschiedenen Arten von Methoden zu kennen und die geeignete Art auszuw╨öhlen. Achtung: Bei Borland Delphi ist es auch m╨ñglich, Felder des Vorfahren zu ╨æberschreiben. Bei Speed-Pascal besteht diese M╨ñglichkeit derzeit nicht. Die Vererbung ist ein transitive Beziehung. Wenn zum Beispiel eine Klasse C von einer Klasse B abstammt, die wiederum von einer Klasse A abstammt, dann erbt B als Nachkomme von A deren Komponenten. C ist Nachkomme von B und damit auch Nachkomme von A. Zu den Komponenten, die C von B erbt, geh╨ñren also auch die von A. Im folgenden Beispiel werden zwei Klassen TWindow und TEditorWindow deklariert. Da TEditorWindow ein Nachfahre von TWindow ist, besitzt die Klasse s╨ömtliche Komponenten von TWindow (FX, FY, FWidth, FHeight und die Methode Draw) sowie die beiden neuen Felder FCursorRow und FCursorColumn. type TWindow = class FX, FY, FWidth, FHeight: Integer; procedure Draw; end; TEditorWindow = class(TWindow) FCursorRow, FCursorColumn: Integer; end; Durch mehrmalige Anwendung der Vererbung entsteht eine baumartige Hierarchie von Klassen. Es gibt keine Beschr╨önkung f╨ær die Anzahl der Nachkommen, die eine Klasse besitzen kann. Jede Klasse hat aber immer genau einen Vorfahren. Wenn nicht explizit ein Vorfahr angegeben wird, dann nimmt der Compiler die in der Unit System vordefinierte Klasse TObject als Vorfahren an. Damit sind die folgenden beiden Klassendeklarationen ╨öquivalent: type TMyObject = class // impliziter Nachkomme von TObject ... end; type TMyObject = class(TObject) // expliziter Nachkomme von TObject ... end; Die Hierarchie der Klassen schl╨ögt sich auch in den Regeln f╨ær Zuweisungskompatibilit╨öt von Objekten nieder, die sich von denen f╨ær traditionelle Datentypen unterscheiden. ΓòÉΓòÉΓòÉ 1.2. Sichtbarkeit ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Sichtbarkeit ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was ist Sichtbarkeit? Die Sichtbarkeit einer Komponente bestimmt, wer diese Komponente sehen und darauf zugreifen kann. Innerhalb des Moduls, in dem eine Klasse deklariert wird, sind immer alle ihre Komponenten uneingeschr╨önkt sichtbar. Die Sichtbarkeit einer Komponente au╤üerhalb dieses Moduls kann mit Hilfe der Schl╨æsselw╨ñrter public, protected und private abgestuft eingeschr╨önkt werden. Zus╨ötzlich existiert mit published eine Art von Sichtbarkeit, die Komponenten einer Klasse im Objekt-Inspektor der Sibyl-Umgebung editierbar macht und spezielle Laufzeitinformationen erzeugt, die von SPCC-Anwendungen ben╨ñtigt werden. Ein Sichtbarkeitsbezeichner wird in der Deklaration der Klasse vor einer Komponente eingef╨ægt. Er gilt ab dieser Stelle entweder f╨ær alle folgenden Komponenten der Klasse, oder bis eine andere Art der Sichtbarkeit festgelegt wird. Die Sichtbarkeit einer Komponente vererbt sich auf die Nachfahren der Klasse, kann aber in Nachfahren ge╨öndert werden, wenn die Komponente dort sichtbar ist. public - ╨⌐ffentliche Komponenten Wenn keine andere Art der Sichtbarkeit vorgegeben wird, dann w╨öhlt der Compiler automatisch public. Komponenten, die als public gekennzeichnet werden, sind sowohl innerhalb als auch au╤üerhalb des Moduls, in dem die Klassendeklaration beheimatet ist, uneingeschr╨önkt sichtbar. public ist die Art von Sichtbarkeit, die ╨æblicherweise f╨ær Komponenten gew╨öhlt wird, die dem Anwender einer Klasse zur Verf╨ægung stehen sollen. protected - Gesch╨ætzte Komponenten protected stellt eine etwas eingeschr╨önktere Art von Sichtbarkeit dar als public. Komponenten, die als protected gekennzeichnet werden, sind innerhalb des Moduls, in dem ihre Klasse deklariert wird, uneingeschr╨önkt sichtbar. Au╤üerhalb des Moduls sind sie nur innerhalb von Methoden von Nachfahren der Klasse sichtbar. protected ist die Art von Sichtbarkeit, die ╨æblicherweise f╨ær Komponenten gew╨öhlt wird, die zwar dem Entwickler von Nachfahren der Klasse zur Verf╨ægung stehen, aber vor dem Anwender einer Klasse verborgen werden sollen. private - Versteckte Komponenten private ist die eingeschr╨önkteste Art von Sichtbarkeit. Komponenten die als private gekennzeichnet werden, sind innerhalb des Moduls, in dem ihre Klasse deklariert wird, uneingeschr╨önkt sichtbar. Au╤üerhalb des Moduls sind sie nicht sichtbar. private ist die Art von Sichtbarkeit, die ╨æblicherweise f╨ær Komponenten gew╨öhlt wird, die im Rahmen der Kapselung g╨önzlich verborgen werden sollen. published - Ver╨ñffentlichte Komponenten published stellt eine besondere Art von Sichtbarkeit dar, die innerhalb der Sibyl-Umgebung zum Einsatz kommt. Komponenten, die als published gekennzeichnet werden, sind sowohl innerhalb als auch au╤üerhalb des Moduls, in dem ihre Klasse deklariert wird, uneingeschr╨önkt sichtbar. Damit verhalten sie sich exakt so wie Komponenten, die als public gekennzeichnet werden. Zus╨ötzlich erzeugt der Compiler aber f╨ær Felder und Eigenschaften mit der Sichtbarkeit published spezielle Laufzeitinformationen, die f╨ær die Zusammenarbeit mit dem Objekt-Inspektor und f╨ær das Laufzeitverhalten von SPCC-Anwendungen von Bedeutung sind. published ist die Art von Sichtbarkeit, die f╨ær Komponenten gew╨öhlt werden mu╤ü, die innerhalb des Objekt-Inspektors editierbar sein sollen. Zus╨ötzlich gelten folgende Einschr╨önkungen f╨ær Komponenten mit der Sichtbarkeit published: - Handelt es sich bei der Komponente um ein Feld, so mu╤ü dieses vom Typ einer Klasse sein. - Handelt es sich bei der Komponente um eine Eigenschaft, so mu╤ü diese einfach, also nicht-indiziert sein. Au╤üerdem ist ihr Typ auf eine der folgenden M╨ñglichkeiten beschr╨önkt: -- Aufz╨öhlungstyp -- Ganzzahliger Typ -- Flie╤ükommazahl -- String -- Mengentyp mit nicht mehr als 16 Elementen -- Objekttyp -- Methodenzeiger ΓòÉΓòÉΓòÉ 1.3. Instanzen ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Instanzen ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was sind Instanzen? Ein Repr╨ösentant einer Klasse wird eine Instanz oder ein Objekt der Klasse genannt. Objekte sind dynamische Datentypen, die zur Laufzeit erzeugt und zerst╨ñrt werden. Eine Klasse legt den Bauplan f╨ær jede ihrer Instanzen fest. Das Erzeugen und Zerst╨ñren von Objekten geschieht mithilfe spezieller Methoden. Zum Erzeugen eines Objekts wird ein Konstruktor aufgerufen, der den vom Objekt ben╨ñtigten Speicherbereich auf dem Heap reserviert und initialisiert. Wird das Objekt nicht mehr ben╨ñtigt, sollte es durch den Aufruf eines Destruktors zerst╨ñrt werden, wodurch auch der reservierte Speicher wieder freigegeben wird. Das Objektmodell von Speed-Pascal basiert auf Referenzen. Eine Variable vom Typ einer Klasse enth╨ölt kein Objekt, sondern einen Zeiger. Dieser Zeiger kann zur Laufzeit ein Objekt referenzieren oder den Wert nil enthalten, um anzudeuten, da╤ü er gerade kein g╨æltiges Objekt referenziert. Beim Erzeugen eines neuen Objekts wird dem Zeiger die Adresse des Speicherbereiches zugewiesen, der f╨ær das Objekt reserviert wurde. Es ist weder notwendig noch m╨ñglich, den Zeiger explizit zu dereferenzieren. Der Compiler erledigt dies bei Bedarf. Beim Zugriff auf die Elemente eines Objekts wird der Zeiger automatisch dereferenziert. Dadurch stellt sich ein Objekt trotz dynamischer Allokation wie eine statische Variable dar. Beim Zugriff auf das gesamte Objekt wird der Zeiger nicht dereferenziert. Stattdessen wird mit dem Wert des Zeigers, also der Adresse der Instanz gearbeitet. Das wirkt sich insbesondere bei Zuweisungen aus. Erzeugen von Instanzen Instanzen werden erzeugt, indem eine spezielle Art von Methode aufgerufen wird, ein sogenannter Konstruktor. Der Konstruktur reserviert den f╨ær die Instanz n╨ñtigen Speicherbereich auf dem Heap und initialisiert das neue Objekt. Die Adresse der Instanz wird in eine Instanzvariable geschrieben, die zuvor deklariert sein mu╤ü. Genauere Informationen zur Implementierung und zum Aufruf von Konstruktoren finden Sie im entsprechenden Abschnitt. Zerst╨ñren von Instanzen Objektinstanzen werden zerst╨ñrt, indem eine spezielle Art von Methode, ein sogenannter Destruktor aufgerufen wird. Der Destruktor f╨æhrt zuerst Code aus, der notwendig ist, um die Benutzung er Objektinstanz korrekt zu beenden. Das schlie╤üt insbesondere die Freigabe untergeordneter Objekte ein. Dieser Code wird vom Programmierer festgelegt. Dann gibt der Destruktor den vom Objekt auf dem Heap belegten Speicherplatz wieder frei. Genauere Informationen zur Implementierung und zum Aufruf von Destruktoren finden Sie im entsprechenden Abschnitt. ΓòÉΓòÉΓòÉ 1.4. Zuweisungen ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Zuweisungen ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was geschieht bei Zuweisungen? Das Objektmodell von Speed-Pascal basiert auf Referenzen. Eine Variable vom Typ einer Klasse bietet nicht Platz f╨ær eine Objektinstanz, sondern nur f╨ær einen Zeiger, der eine Objektinstanz referenzieren kann. Bei einer Zuweisung wird demzufolge keine Kopie des Quellobjektes erstellt. Stattdessen wird die Adresse des Objektes auf der rechten Seite der Zuweisung in die Variable auf der linken Seite der Zuweisung geschrieben. Dadurch referenzieren beide Variablen nach der Zuweisung das gleiche Objekt, was auch das folgende Beispiel verdeutlicht. var A, B: TObject; begin A.Create; // Erzeugt eine Instanz von TObject. Die // Variable A referenziert diese Instanz. B := A; // Weist B den Wert von A zu. Beide Variablen // referenzieren nun das gleiche Objekt. B.Destroy; // Zerst╨ñrt die von B referenzierte Instanz. // Damit ist auch der Wert von A ung╨æltig. end. Zuweisungskompatibilit╨öt Durch den Vererbungsmechanismus ergeben sich verwandtschaftliche Beziehungen zwischen Klassen. Diesen Beziehungen wird durch erweiterte M╨ñglichkeiten bei Zuweisungen Rechnung getragen. Au╤üer mit sich selbst ist eine Klasse zuweisungskompatibel mit all ihren Vorfahren. Das schlie╤üt sowohl den einen direkten als auch jeden weiteren indirekten Vorfahren ein. Zur Laufzeit kann eine Variable vom Typ einer Klasse A also eine Instanz genau dieser Klasse A oder eines beliebigen Nachfahren von A referenzieren. Umgekehrt gilt diese Zuweisungskompatibilit╨öt nicht. Eine Klasse ist mit keinem ihrer Nachfahren zuweisungskompatibel. Zwischen g╨önzlich unverwandten Klassen, die v╨ñllig verschiedenen ╨₧sten der Objekthierarchie entstammen, besteht ebenfalls keinerlei Zuweisungskompatibilit╨öt. Folgendes Beispiel demonstriert eine Reihe von legalen und illegalen Zuweisungen. Illegale Zuweisungen werden vom Compiler erkannt und nicht akzeptiert. type TVehicle = class(TObject); TShip = class(TVehicle); TSubmarine = class(TShip); TAirplane = class(TVehicle); var Vehicle: TVehicle; Ship: TShip; Submarine: TSubmarine; Airplane: TAirplane; begin // Die folgenden Zuweisungen sind g╨æltig. Vehicle := Ship; Vehicle := Submarine; Vehicle := Airplane; Ship := Submarine; // Die folgenden Zuweisungen sind ung╨æltig // und werden vom Compiler nicht akzeptiert. Ship := Vehicle; // TShip ist Nachkomme von TVehicle. Submarine := Vehicle; // TSubmarine ist Nachkomme von TVehicle. Airplane := Vehicle; // TAirplane ist Nachkomme von TVehicle. Submarine := Ship; // TSubmarine ist Nachkomme von TShip. Ship := Airplane; // TShip und TAirplane sind nicht verwandt. Airplane := Ship; // TAirplane und TShip sind nicht verwandt. end. Typwandlungen Bei Objekten k╨ñnnen - wie bei anderen Datentypen auch - Typwandlungen durchgef╨æhrt werden. Durch eine Typwandlung wird die Typpr╨æfung von Speed-Pascal bewu╤üt unterlaufen, wodurch sich potentielle Gefahren ergeben. Um diese Gefahren zu minimieren, bietet Speed-Pascal mit is und as zwei Operatoren, die unter anderem sichere Typwandlungen erm╨ñglichen. Der Operator is Der Operator is dient dazu, zur Laufzeit eine Typpr╨æfung f╨ær ein Objekt durchzuf╨æhren. Die Syntax ist: MyObject is MyClass Das Ergebnis dieses Ausdrucks ist vom Typ Boolean. Zur Laufzeit wird der tats╨öchliche Typ des Objekts MyObject mit der Klasse MyClass verglichen. Ist der Typ von MyObject identisch mit MyClass oder einem beliebigen direkten oder indirekten Nachfahren von MyClass, dann ist das Ergebnis des Ausdrucks True. In allen anderen F╨öllen, insbesondere wenn MyObject nil ist, liefert die Anwendung des Operators den Wert False. type TVehicle = class(TObject); TShip = class(TVehicle); TAirplane = class(TVehicle); var MyVehicle: TVehicle; begin ... if MyVehicle is TShip then WriteLn('Es ist ein Schiff.') else if MyVehicle is TAirplane then WriteLn('Es ist ein Flugzeug.'); ... end. Beachten Sie, da╤ü MyClass nicht unmittelbar den Namen einer Klasse angeben mu╤ü, sondern auch eine Variable vom Typ einer Metaklasse sein kann. Die tats╨öchliche Klasse wird dann zur Laufzeit dieser Variablen entnommen. N╨öheres dazu entnehmen Sie bitte dem Abschnitt ╨æber Metaklassen. Der Operator as Der Operator as dient dazu, zur Laufzeit sichere Typwandlungen durchzuf╨æhren. Die Syntax ist: MyObject as MyClass Das Ergebnis des Ausdrucks ist vom Typ MyClass. Zur Laufzeit wird anhand des tats╨öchlichen Typs von MyObject gepr╨æft, ob die Typwandlung sicher ist. Als sicher gilt die Typwandlung genau dann, wenn MyClass identisch mit dem tats╨öchlichen Typ von MyObject oder ein direkter oder indirekter Vorfahre davon ist. Ist diese Bedingung nicht erf╨ællt, dann wird eine Exception ausgel╨ñst. Sie k╨ñnnen den Operator mit with..do kombinieren, um eine Reihe von Operationen auf einem Objekt nur dann durchzuf╨æhren, wenn das Objekt zuweisungskompatibel zu einer bestimmten Klasse ist. var MyStream: TStream; begin ... with MyStream as THandleStream do // Wenn MyStream zuweisungskompatibel begin // zu THandleStream ist, dann wird der WriteLn('Handle: ', Handle); // Block ausgef╨æhrt. Sonst wird eine end; // Exception ausgel╨ñst. ... end; Beachten Sie, da╤ü MyClass nicht unmittelbar den Namen einer Klasse angeben mu╤ü, sondern auch eine Variable vom Typ einer Metaklasse sein kann. Die tats╨öchliche Klasse wird dann zur Laufzeit dieser Variablen entnommen. N╨öheres dazu entnehmen Sie bitte dem Abschnitt ╨æber Metaklassen. Beachten Sie au╤üerdem, da╤ü die Typwandlung auch dann als sicher gilt, wenn MyObject den Wert nil enth╨ölt. Wenn Sie nicht sicher sind, ob MyObject wirklich ein g╨æltiges Objekt referenziert, dann sollten Sie dies zuerst pr╨æfen. Anderenfalls riskieren Sie den Abbruch des Programms mit einer Schutzverletzung. ΓòÉΓòÉΓòÉ 1.5. Felder ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûä Felder ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was sind Felder? Felder sind Variablen innerhalb einer Klasse. Sie entsprechen in Deklaration und Anwendung weitgehend den Feldern von Records. Jedes Objekt verf╨ægt ╨æber einen eigenen Satz aller Felder seiner Klasse, insbesondere auch der Felder, die die Klasse von ihren Vorfahren geerbt hat. Das ╨₧ndern eines Feldes von Objekt A hat keinen Einflu╤ü auf das gleichnamige Feld eines Objekts B der gleichen Klasse, solange die Variablen A und B nicht die gleiche Instanz referenzieren. Hingegen teilen sich alle Objekte einer Klasse den gleichen Satz Methoden, wodurch deren Code nur einmal vorhanden ist. Deklaration von Feldern Felder werden auf die folgende Weise deklariert: <Syntaxdiagramm: Fields> Es ist in Speed-Pascal ╨æblich, wenngleich nicht zwingend vorgeschrieben, da╤ü Feldbezeichner mit einem F beginnen. Folgendes Beispiel zeigt die Deklaration von Feldern. type TCity = class FName: string; FLongitude, FLatitude: Integer; FPopulation: LongWord; end; Alle Instanzen der Klasse TCity verf╨ægen ╨æber ihre eigenen Felder zur Aufnahme von Name, geographischer Position und Bev╨ñlkerungszahl einer Stadt. Benutzen von Feldern Die Zugriffe auf die Felder eines Objekts entsprechen den Zugriffen auf Felder von Records. Einzelne Felder k╨ñnnen ╨æber den Punkt und den Bezeichner des Feldes selektiert werden. Au╤üerdem kann eine Operation auf einem Objekt durch with..do angef╨æhrt werden, wodurch alle Felder des Objekts direkt ansprechbar werden. type TCompiler = class FName: string; FVersionHi, FVersionLo: Integer; end; var MyCompiler: TCompiler; begin ... // Qualifizierter Zugriff auf die Felder des Objekts. MyCompiler.FName := 'Speed-Pascal/2'; MyCompiler.FVersionHi := 2; MyCompiler.FVersionLo := 0; // Zugriff auf die Felder mit Hilfe von WITH..DO. Die // folgende Sequenz hat die gleiche Wirkung wie die // vorangehende. with MyCompiler do begin FName := 'Speed-Pascal/2'; FVersionHi := 2; FVersionLo := 0; end; // Lesender Zugriff, WITH..DO ohne BEGIN..END. with MyCompiler do WriteLn(FName, ' Version ', FVersionHi, '.', FVersionLo); ... end. ΓòÉΓòÉΓòÉ 1.6. Methoden ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Methoden ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was sind Methoden? Methoden sind Prozeduren oder Funktionen, deren Funktionalit╨öt fest mit einer Klasse verkn╨æpft ist. Methoden werden ╨æblicherweise in Verbindung mit einer Instanz der Klasse aufgerufen. Bei Klassenmethoden ist auch ein Aufruf in Verbindung mit einer Klasse m╨ñglich. Felder, Methoden und Eigenschaften einer Klasse sind innerhalb der Implementierung ihrer Methoden verf╨ægbar. Methoden werden an Nachfahren vererbt. Alle Instanzen einer Klasse teilen sich den gleichen Satz Methoden, so da╤ü deren Code nur einmal im Programm vorhanden ist. Es gibt eine Reihe von Schl╨æsselw╨ñrtern, die das Laufzeitverhalten einer Methode beeinflussen. W╨öhrend bei statischen Methoden die Aufrufadresse bereits zur Zeit der Compilierung feststeht, wird sie bei virtuellen und dynamischen Methoden erst zur Laufzeit ermittelt. Zus╨ötzlich existieren botschaftsverarbeitende Methoden, die das Zusammenspiel verschiedener Bildschirmelemente mit dem Betriebssystem ╨æber den Austausch von Nachrichten koordinieren. Zwei spezielle Arten von Methoden, Konstruktoren und Destruktoren, dienen zum Erzeugen und Zerst╨ñren von Objektinstanzen. Deklarieren von Methoden Methoden werden auf die folgende Weise deklariert: <Syntaxdiagramm: Methods> Folgendes Beispiel deklariert eine Klasse TWindow zur Darstellung eines Fensters auf dem Bildschirm. Die Klasse enth╨ölt zwei Methoden zum Lesen und Schreiben des Fenstertitels. type TWindow = class ... function GetTitle: string; procedure SetTitle(const S: string); ... end; Implementieren von Methoden Die Methoden einer Klasse werden nach der Deklaration der Klasse implementiert, ╨öhnlich der Implementierung einer als forward deklarierten Prozedur oder Funktion. Falls die Klasse in einer Unit deklariert wird, findet die Implementierung der Methoden im implementation-Teil der Unit statt. Jeder einzelnen Methode geht bei der Implementierung der Name der Klasse gefolgt von einem Punkt voran. Die Liste formaler Parameter der Methode kann, mu╤ü aber nicht bei der Implementierung wiederholt werden. Wenn sie wiederholt wird, dann mu╤ü sie exakt mit der Parameterliste der Deklaration ╨æbereinstimmen. type TWindow = class X, Y, Width, Height: Integer; Title: string; ... procedure Draw; procedure SetPosition(X, Y: Integer); procedure SetTitle(const S: string); end; // Draw besitzt keine Parameter. procedure TWindow.Draw; begin ... end; // Bei SetPosition wird die gesamte Parameterliste wiederholt. procedure TWindow.SetPosition(X, Y: Integer); begin ... end; // Bei SetTitle wird die gesamte Parameterliste weggelassen. procedure TWindow.SetTitle; begin ... end; Der G╨æltigkeitsbereich aller Komponenten einer Klasse erstreckt sich unter anderem auf die Implementierung aller Methoden der Klasse. Dadurch sind alle Felder, Methoden und Eigenschaften der Klasse innerhalb der Methode direkt zugreifbar. procedure TWindow.SetTitle(const S: string); begin FTitle := S; Draw; end; Zus╨ötzlich existiert in jeder Methode ein impliziter Parameter Self, der vom Typ der Klasse ist, zu der die Methode geh╨ñrt. Self referenziert zur Laufzeit stets das Objekt, auf dem die Methode aufgerufen wurde. Wenn durch eine with..do-Anweisung oder durch formale Parameter der Methode Komponenten der Klasse aus dem aktuellen G╨æltigkeitsbereich verdr╨öngt werden, dann kann ╨æber Self weiterhin auf diese Komponenten zugegriffen werden. procedure TWindow.SetPosition(X, Y: Integer); begin // Der Konflikt zwischen den Feldern X, Y und den // gleichnamigen formalen Parametern wird durch // Self gel╨ñst. Self.X := X; Self.Y := Y; Draw; end; Falls innerhalb der Implementierung einer Methode einer Klasse auf eine gleichnamige Methode des Vorfahren zugegriffen werden soll, die in der neuen Klasse ╨æberschrieben oder verdeckt wurde, dann ist dies mit dem Schl╨æsselwort inherited m╨ñglich. type TEditorWindow = class(TWindow) procedure Draw; end; procedure TWindow.Draw; begin DrawFrameAndTitle; // Soll den den Rahmen und die Titelzeile zeichnen. end; procedure TEditorWindow.Draw; begin inherited Draw; // Ruft zuerst TWindow.Draw auf. DrawContents; // Soll den Inhalt des Editor-Fensters zeichnen. end; Aufruf von Methoden Der Aufruf einer Methode geschieht durch Angabe der Instanz, auf der die Methode operieren soll, gefolgt von einem Punkt, dem Namen der Methode und der Liste aktueller Parameter. Innerhalb einer with..do-Anweisung, die eine Objektinstanz in den aktuellen G╨æltigkeitsbereich r╨æckt, kann die Angabe der Instanz auch entfallen. type TWindow = class procedure SetPosition(X, Y: Integer); end; var MyWindow: TWindow; begin ... MyWindow.SetPosition(100, 200); // Qualifizierter Aufruf. ... with MyWindow do begin SetPosition(100, 200); // Aufruf innerhalb von WITH..DO end; // ben╨ñtigt keine Angabe der Instanz. ... end. Bei Klassenmethoden besteht zus╨ötzlich die M╨ñglichkeit, die Methode mit dem Bezeichner einer Klasse anstelle der Objektinstanz aufzurufen. Welche Methode zur Laufzeit tats╨öchlich aufgerufen, h╨öngt wesentlich davon ab, welches Laufzeitverhalten f╨ær die Methode gew╨öhlt wurde. W╨öhrend bei statischen Methoden die Bindung bereits zur Zeit der Compilierung durchgef╨æhrt wird, ermittelt bei virtuellen oder dynamischen Methoden das Laufzeitsystem anhand des tats╨öchlichen Typs der Instanz, welche Methode aufgerufen wird. Spezielle Arten von Methoden Statische Methoden Sofern bei der Deklaration einer Methode keine andere Art der Methodenzuteilung gew╨öhlt wird, ist die Methode statisch. Die Adresse der aufzurufenden Methode steht dann bereits zur Zeit der Compilierung fest und wird vom Linker fest ins Programm eingetragen. Virtuelle Methoden Das Laufzeitverhalten einer Methode wird als virtuell festgelegt, wenn an die Deklaration der Methode das Schl╨æsselwort virtual angeh╨öngt wird. Bei virtuellen Methoden steht die Adresse des Aufrufes nicht bereits zur Zeit der Compilierung fest. Stattdessen wird diese Entscheidung auf die Laufzeit des Programms verschoben. Das Laufzeitsystem ermittelt anhand des tats╨öchlichen Typs der Instanz, welche Methode aufgerufen wird. Wenn eine Methode einmal als virtuell festgelegt wird, dann gilt dies automatisch auch f╨ær alle Nachfahren der Klasse, zu der die Methode geh╨ñrt. Das bedeutet insbesondere, da╤ü die einmal festgelegte Liste formaler Parameter beim ╨¬berschreiben der Methode beibehalten werden mu╤ü. Zum ╨¬berschreiben einer virtuellen Methode wird das Schl╨æsselwort override anstelle von virtual eingesetzt. Folgendes Beispiel zeigt einen typischen Einsatzfall f╨ær eine virtuelle Methode. Verschiedene graphische Bildschirmelemente besitzen eine Methode Draw, mit der sie neu gezeichnet werden. Dadurch, da╤ü diese Methode virtuell ist, wird zur Laufzeit stets die zur Instanz passende Version von Draw aufgerufen. Bei einer statischen Methode hingegen w╨ærde stets die Version von Draw aufgerufen, die zum deklarierten Typ der Variablen geh╨ñrt, im Beispiel also TWindow.Draw. type TWindow = class(TObject) procedure Draw; virtual; // Kennzeichnet die Methode als virtuell. end; TEditorWindow = class(TWindow) procedure Draw; override; // ╨¬berschreibt die virtuelle Methode. end; ... var MyWindow: TWindow; begin MyWindow := TWindow.Create; // Erzeugt eine Instanz von TWindow. MyWindow.Draw; // Ruft TWindow.Draw auf. MyWindow.Destroy; // Zerst╨ñrt die Instanz. MyWindow := TEditorWindow.Create; // Erzeugt eine neue Instanz von // TEditorWindow MyWindow.Draw; // Ruft TEditorWindow.Draw auf. W╨öre // Draw nicht virtuell, w╨ærde hier // auch TWindow.Draw aufgerufen, was // in diesem Fall sicher nicht sehr // sinnvoll ist. MyWindow.Destroy; // Zerst╨ñrt die Instanz. end. Es ist auch m╨ñglich, eine virtuelle Methode in einem Nachfahren neu zu deklarieren. Dadurch wird die geerbte virtuelle Methode in der neuen Klasse verdeckt, analog zu einer statischen Methode, die durch die Neudeklaration einer statischen Methode gleichen Namens verdeckt wird. Die neu deklarierte Methode mu╤ü dabei wieder eine als virtual gekennzeichnete virtuelle Methode sein, jedoch kann sich ihre Liste formaler Parameter von der der verdeckten Methode unterscheiden. Das Verhalten von auf diese Weise neu deklarierten virtuellen Methoden ist aber unter Umst╨önden schwerer zu durchschauen als das von ╨æberschriebenen virtuellen Methoden. Sie sollten deshalb eine einmal als virtuell gekennzeichnete Methode stets mit override ╨æberschreiben. Achtung: Im Gegensatz zu Borland Delphi ist es bei Speed-Pascal derzeit nicht m╨ñglich, da╤ü eine virtuelle Methode durch die Neudeklaration einer statischen Methode in einem Nachfahren verdeckt wird. Der Compiler verbietet dies, um Fehler seitens des Programmierers abzufangen. Normalerweise handelt es sich dabei eher um ein vergessenes override als um eine gewollte Neudeklaration. Diese Art von Fehler ist aber meist schwer zu entdecken, weil das Programm korrekt compiliert wird, und sich das falsche Verhalten der Methode nur in einzelnen F╨öllen und oft nur auf sehr subtile Weise bemerkbar macht. Virtuelle Methoden werden vom Compiler mit Hilfe einer Tabelle virtueller Methoden realisiert. Jede Klasse besitzt eine solche Tabelle mit den Einsprungadressen aller ihrer virtuellen Methoden. Zur Laufzeit wird die Adresse der aufzurufenden Methode aus dieser Tabelle ermittelt. Der Aufrufmechanismus ist sehr schnell, ben╨ñtigt aber dennoch minimal mehr Zeit als der Aufruf einer statischen Methode. Virtuelle Methoden sind ein m╨öchtiges Hilfsmittel, um Polymorphie zu erreichen. Dynamische Methoden Das Laufzeitverhalten einer Methode wird als dynamisch festgelegt, wenn an die Deklaration der Methode das Schl╨æsselwort dynamic angeh╨öngt wird. Dynamische Methoden verhalten sich exakt so wie virtuelle Methoden, insbesondere was das ╨¬berschreiben und die Neudeklaration betrifft. Achtung: Das Schl╨æsselwort existiert nur aus Gr╨ænden der Kompatibilit╨öt zu Borland Delphi. Programme, die auf dynamische Methoden zur╨æckgreifen, werden unter Speed-Pascal problemlos funktionieren. Jedoch werden sie vermutlich geringf╨ægige Unterschiede in Ausf╨æhrungsgeschwindigkeit und Speicherbedarf aufweisen. Abstrakte Methoden Eine virtuelle oder dynamische Methode wird zu einer abstrakten Methode, wenn an die Deklaration der Methode das Schl╨æsselwort abstract angeh╨öngt wird. Nur virtuelle und dynamische Methoden k╨ñnnen abstrakt sein, nicht jedoch statische. Das Schl╨æsselwort abstract mu╤ü dabei dem Schl╨æsselwort virtual oder dynamic folgen. Abstrakte Methoden werden nicht implementiert, k╨ñnnen jedoch von anderen Methoden oder von Code, der nicht Teil einer Methode ist, benutzt werden. Ihr Sinn liegt darin, ein funktionsloses Interface bereitzustellen, das von Nachfahren einer Klasse aufrechterhalten werden mu╤ü. Spezialisierte Nachfahren m╨æssen abstrakte Methoden mit override ╨æberschreiben, wenn die Methode tats╨öchlich genutzt werden soll. Der Aufruf einer abstrakten Methode auf einer Instanz, deren Klasse die Methode nicht ╨æberschreibt, f╨æhrt zu einem Laufzeitfehler. Innerhalb der Implementierung einer Methode, die eine abstrakte Methode ╨æberschreibt, kann nicht mit inherited auf die Methode des Vorfahren zugegriffen werden. Folgendes Beispiel deklariert eine Basisklasse TContainer f╨ær Container-Objekte. Sie verf╨ægt ╨æber zwei abstrakte Methoden zum Vergleich und zum Vertauschen zweier Elemente anhand ihrer Indizes. Au╤üerdem beinhaltet die Klasse eine Sortiermethode. Innerhalb der Sortiermethode k╨ñnnen die beiden abstrakten Methoden type TContainer = class FSize: Integer; function BiggerThan(Item1, Item2: Integer): Boolean; virtual; abstract; procedure Swap(Item1, Item2: Integer); virtual; abstract; procedure BubbleSort; end; procedure TContainer.BubbleSort; var N, I: Integer; begin for N := FSize downto 2 do for I := 1 to N - 1 do if BiggerThan(I, I + 1) then Swap(I, I + 1); end; Botschaftsverarbeitende Methoden Eine Methode wird zu einer botschaftsverarbeitenden Methode, indem an ihre Deklaration das Schl╨æsselwort message gefolgt von einer ganzzahligen, positiven Konstanten angeh╨öngt wird. Zus╨ötzlich mu╤ü die Methode eine Prozedurmethode sein, die ╨æber genau einen var-Parameter beliebigen Typs verf╨ægt. Auch ein untypisierter var-Parameter ist erlaubt. type TMyButton = class(TButton) ... procedure WMButton1Down(var Message); message WM_BUTTON1DOWN; ... end; Botschaftsverarbeitende Methoden dienen ╨æblicherweise zum Austausch von Nachrichten mit dem Betriebssystem, insbesondere bei der Programmierung von graphischen Oberfl╨öchen wie dem OS/2 Presentation Manager oder Windows. So wird zum Beispiel bei einem Tastendruck oder einem Mausklick vom Betriebssystem eine Botschaft an das zugeh╨ñrige Bildschirmobjekt gesandt, das diese Botschaft dann verarbeiten mu╤ü. Es wird genau die botschaftsverarbeitende Methode aufgerufen, deren hinter message angegebene Nummer mit der Identifikation der Nachricht ╨æbereinstimmt. Es ist m╨ñglich, weitere Informationen an eine solche Methode zu ╨æbergeben. Dazu dient der var-Parameter, der die ╨¬bergabe fast beliebiger Typen erlaubt. Wichtig f╨ær das Funktionieren des Botschaftsmechanismus ist nur, da╤ü die ersten vier Byte des Parameters die Nummer der Botschaft enthalten. Die darauf folgenden Daten k╨ñnnen vom Programmierer frei gew╨öhlt werden. Damit sehen alle zul╨össigen Parameter-Typen etwa wie folgt aus: type TMessageRec = record MessageID: LongWord; // Die Identifikation der Nachricht. ... // Ab hier beliebige weitere Informationen. end; Der OS/2 Presentation Manager und Windows erlauben beim Austausch die ╨¬bergabe von zwei zus╨ötzlichen 32 Bit breiten Parametern, die je nach Art der Nachricht in mehrere logische 16 oder 8 Bit breite Parameter unterteilt sein k╨ñnnen. Daher ist f╨ær Anwendungen, die auf die SPCC-Bibliothek zur╨æckgreifen, in der Unit Classes bereits ein Botschaftstyp TMessage deklariert, der diesen Fall abdeckt. Es ist m╨ñglich und ausgesprochen sinnvoll, botschaftsverarbeitende Methoden bei Nachfahren einer Klasse zu ╨æberschreiben, um ein vom Vorfahren abweichendes Verhalten bei bestimmten Nachrichten zu realisieren. Anders als bei virtuellen Methoden ist hier beim ╨¬berschreiben das Schl╨æsselwort override nicht notwendig. Botschaftsverarbeitende Methoden sind immer dynamisch gebunden; das hei╤üt, die Adresse des Aufrufes wird immer zur Laufzeit anhand des tats╨öchlichen Typs der Instanz ermittelt. Dazu legt der Compiler f╨ær jede Klasse eine Tabelle von botschaftsverarbeitenden Methoden mit deren Nummern und Einsprungsadressen an. Die Informationen dieser Tabelle werden von einer Methode Dispatch ausgewertet, die von TObject bereitgestellt wird. Da alle Objekte Nachfahren von TObject sind, steht diese Methode in jedem Objekt zur Verf╨ægung. procedure Dispatch(var Message); Botschaftsverarbeitende Methoden werden ╨æblicherweise nicht direkt aufgerufen, sondern ╨æber einen Aufruf von Dispatch mit einem geeigneten Parameter, der die Nummer der Nachricht und m╨ñglicherweise weitere Informationen enth╨ölt. Dispatch erledigt das Auffinden der zur Botschaft passenden Methode und ruft diese dann auf. Dazu sucht Dispatch sucht zuerst in der Tabelle der tats╨öchlichen Klasse der Instanz nach einer Methode mit der in der Botschaft enthaltenen Nummer. Ist dort keine solche Methode enthalten, wird die Tabelle des Vorfahren der Klasse durchsucht, dann die von dessen Vorfahren, und so weiter. Es ist wichtig zu wissen, da╤ü f╨ær den Aufruf einer botschaftsverarbeitenden Methode ╨æber Dispatch nur deren Nummer entscheidend ist. Der Name der Methode ist v╨ñllig irrelevant. Es ist insbesondere m╨ñglich, eine botschaftsverarbeitende Methode durch eine Methode v╨ñllig anderen Namens zu ╨æberschreiben, solange nur die Nummern ╨æbereinstimmen. Enth╨ölt beim Aufruf von Dispatch der gesamte in Frage kommende Zweig der Klassenhierarchie keine Methode mit der angegebenen Nummer, dann wird eine virtuelle Methode DefaultHandler aufgerufen, die von der Basisklasse TObject wie folgt bereitgestellt wird: procedure DefaultHandler(var Message); virtual; Diese Methode tut ╨æberhaupt nichts. Es ist aber m╨ñglich, DefaultHandler zu ╨æberschreiben, um ein anderes Standardverhalten bei unbehandelten Nachrichten zu implementieren, zum Beispiel die Ausgabe einer Fehlermeldung. Die graphischen Bildschirmelemente der SPCC-Bibliothek ╨æberschreiben diese Methode derart, da╤ü vom Objekt nicht behandelte Nachrichten an eine Betriebssystem-Routine ╨æbergeben werden, die eine passende Standard-Aktion f╨ær das entsprechende Bildschirmelement durchf╨æhrt. Konstruktoren Konstruktoren sind spezielle Methoden, deren Aufruf ein neues Objekt erzeugt und initialisiert. Konstruktoren werden bei Deklaration und Implementierung durch das Schl╨æsselwort constructor eingeleitet. Ein Konstruktor darf eine beliebige Liste formaler Parameter haben, aber keinen Wert zur╨æckliefern. Er hat also die Gestalt einer Prozedurmethode. Es gibt zwei Varianten, einen Konstruktor aufzurufen. Die eine entspricht dem Aufruf einer gew╨ñhnlichen Methode auf einer Instanzvariablen, nur da╤ü diese Variable vor dem Aufruf des Konstruktors noch kein g╨æltiges Objekt referenziert. Es wird ein Objekt erzeugt und initialisiert, dessen Typ dem der Instanzvariablen entspricht. Die Adresse dieses Objekts wird in die Instanzvariable geschrieben. type TCustomer = class(TObject) private FName: PString; public constructor Create(Name: string); end; constructor TCustomer.Create(Name: string); begin FName := NewStr(Name); end; var Customer: TCustomer; begin // Erzeuge eine Instanz von TCustomer. Customer.Create('Thomas Jefferson'); end. Die andere Variante ben╨ñtigt die Angabe einer Klasse anstelle der Instanzvariablen. Das Ergebnis dieses Aufrufes mu╤ü im Rahmen einer Zuweisung an eine Instanzvariable ╨æbergeben werden. Bei dieser Variante ist es m╨ñglich, Objekte zu erzeugen, deren Typ nicht exakt dem der Variablen entspricht, sofern die Regeln f╨ær Zuweisungskompatibilit╨öt eingehalten werden. type TMailOrderCustomer = class(TCustomer) private FAddress: PString; public constructor Create(Name, Address: string); end; constructor TMailOrderCustomer.Create(Name, Address: string); begin inherited Create(Name); FAddress := NewStr(Address); end; var Customer1, Customer2: TCustomer; begin // Erzeuge eine Instanz von TCustomer. Customer1 := TCustomer.Create('Thomas Jefferson'); // Erzeuge eine Instanz von TMailOrderCustomer. Da diese Klasse // zuweisungskompatibel zu TCustomer ist, kann Customer2 diese // Instanz referenzieren. Customer2 := TMailOrderCustomer.Create('George Washington', 'White-House, Washington, DC'); end. Achtung: Bei Borland Delphi ist nur die zweite Variante m╨ñglich. Wenn Programme entwickelt werden, deren Quellcode zwischen Speed-Pascal und Delphi ausgetauscht werden soll, dann mu╤ü die erste Variante vermieden werden, was aber keinerlei Einschr╨önkung der Funktionalit╨öt des Programms darstellt. Beim Aufruf eines Konstruktors werden automatisch folgende Aktionen ausgef╨æhrt: - Der f╨ær die Objektinstanz ben╨ñtigte Speicher wird auf dem Heap reserviert. Die Adresse des Speicherbereiches wird in die Instanzvariable geschrieben, mit der Konstruktor aufgerufen wurde. - Der reservierte Speicherbereich wird mit Nullen gef╨ællt. Dadurch erh╨ölt jedes Feld des neuen Objekts einen definierten Zustand. Welcher Zustand dies ist, h╨öngt vom Typ des Feldes ab: -- Ganzzahlen und Flie╤ükommazahlen erhalten den Wert Null. -- Zeiger und Objektreferenzen erhalten den Wert nil. -- Einzelne Zeichen erhalten das Nullzeichen Chr(0). -- Strings erhalten die L╨önge Null. -- Felder vom Typ Boolean erhalten den Wert False. -- Bei strukturierten Feldern wie Records und Arrays gelten diese Regeln f╨ær alle Elemente. - Der Benutzercode des Konstruktors, also die Folge der Anweisungen zwischen begin und end, wird ausgef╨æhrt. Bei der Implementierung eines Konstruktors sollten die Schritte ausgef╨æhrt werden, die n╨ñtig sind, um eine neue Instanz korrekt zu initialisieren. Es ist m╨ñglich, mit inherited den Konstruktor des Vorfahren aufzurufen. Dabei wird nur der Benutzercode des geerbten Konstruktors ausgef╨æhrt, nicht aber eine weitere Instanz erzeugt. Es ist ╨æblich, zuerst den Konstruktor des Vorfahren aufzurufen, um die von Vorfahren geerbten Fehler zu initialisieren. Im Anschlu╤ü werden meist die zus╨ötzlichen Fehler der neuen Klasse initialisiert. Eine Klasse, die keine Felder zus╨ötzlich zu denen ihres Vorfahren deklariert oder deren Felder bei der Initialisierung alle auf Null gesetzt werden m╨æssen, kommt eventuell ohne eigenen Konstruktor aus. Der Konstruktor des Vorfahren, im Extremfall der von TObject, kann diese Aufgabe ╨æbernehmen. Wenn w╨öhrend des Konstruktoraufrufes an einer beliebigen Stelle eine Exception ausgel╨ñst wird, dann wird zuerst zum Destruktor verzweigt, bevor die Exception-Behandlungsroutine angesprungen oder ein Laufzeitfehler ausgel╨ñst wird. Deshalb ist es notwendig, da╤ü der Destruktor auf diesen Fall reagieren kann, also auch in der Lage ist, nur teilweise initialisierte Objekte zu zerst╨ñren. Konstruktoren k╨ñnnen virtuell sein. Dadurch wird polymorphes Erzeugen von Objekten m╨ñglich, also von Objekten, deren exakter Typ zur Zeit der Compilierung noch nicht bekannt ist. Ein virtueller Konstruktor mu╤ü immer in der Zuweisungsvariante aufgerufen werden. Genaueres dazu befindet sich im Abschnitt ╨æber Metaklassen. Destruktoren Destruktoren sind spezielle Methoden, deren Aufruf ein Objekt zerst╨ñrt. Destruktoren werden bei Deklaration und Implementierung durch das Schl╨æsselwort destructor eingeleitet. Ein Destruktor darf eine beliebige Liste formaler Parameter haben, was aber ╨æblicherweise nicht der Fall ist. Ein Destruktor darf keinen Wert zur╨æckliefern, hat also die Gestalt einer Prozedurmethode. Destruktoren sollten virtuell sein, damit sichergestellt ist, da╤ü zur Laufzeit der zur Instanz passende Destruktor aufgerufen wird. Jede Klasse erbt von TObject einen virtuellen, parameterlosen Destruktor Destroy. Es wird empfohlen, da╤ü Sie diesen Destruktor in Ihren eigenen Klassen mit override ╨æberschreiben. Ein Destruktor wird auf die gleiche Weise aufgerufen wie eine gew╨ñhnliche Methode. Er f╨æhrt zuerst den Benutzercode, also die Anweisungsfolge zwischen begin und end aus, dann gibt er den von der Instanz ben╨ñtigten Speicher auf dem Heap frei. Es ist m╨ñglich, innerhalb eines Destruktors mit inherited auf den Destruktor des Vorfahren zuzugreifen. In diesem Fall wird nur der Benutzercode des geerbten Destruktors ausgef╨æhrt, die Instanz wird aber erst beim Beenden des ╨æbergeordneten Destruktoraufrufes zerst╨ñrt. type TCustomer = class(TObject) private FName: PString; public constructor Create(Name: string); destructor Destroy; override; end; constructor TCustomer.Create(Name: string); begin FName := NewStr(Name); end; destructor TCustomer.Destroy; begin DisposeStr(FName); end; var Customer: TCustomer; begin // Erzeuge eine Instanz. Customer.Create('Thomas Jefferson'); // Zerst╨ñre die Instanz wieder. Customer.Destroy; end. Eine Klasse, die keine Felder zus╨ötzlich zu denen ihres Vorfahren deklariert oder deren Felder nur einfache, nicht-verzeigerte Strukturen enthalten, ben╨ñtigt m╨ñglicherweise keine speziellen Aufr╨öumaktionen zum Zerst╨ñren des Objekts. In diesem Fall kann der Destruktor des Vorfahren benutzt werden, und es mu╤ü kein eigener Destruktor deklariert werden. Ob dies so ist, m╨æssen Sie von Fall zu Fall entscheiden. Wenn w╨öhrend eines Konstruktoraufrufes eine Exception auftritt, dann wird zuerst zum Destruktor verzweigt, bevor die Exception-Behandlungsroutine angesprungen oder ein Laufzeitfehler ausgel╨ñst wird. Deshalb ist es notwendig, da╤ü ein Destruktor auf diesen Fall reagieren kann, also auch in der Lage ist, nur teilweise initialisierte Objekte zu zerst╨ñren. Das ist insbesondere wichtig, wenn das Objekt ╨æber Felder von Zeiger- oder Objekttypen verf╨ægt. Der Destruktor sollte diese Felder auf nil pr╨æfen, bevor er versucht, die zugeh╨ñrigen Strukturen freizugeben. Das Zerst╨ñren eines Objektes kann sicherer gestaltet werden, wenn statt des Destruktors die Methode Free aufgerufen wird, die alle Klassen von TObject erben. Free pr╨æft, ob die Instanz den Wert Nil enth╨ölt, und ruft nur dann den Destruktor Destroy auf, wenn das nicht der Fall ist. Klassenmethoden Klassenmethoden sind Prozedur- oder Funktionsmethoden, denen bei Deklaration und Implementierung zus╨ötzlich das Schl╨æsselwort class vorangestellt wird. Sie k╨ñnnen virtuell sein, d╨ærfen dann aber wieder nur durch Klassenmethoden ╨æberschrieben werden. Die Regeln sind hierbei die gleichen, die auch bei gew╨ñhnlichen virtuellen Methoden gelten. type TConfigFile = class ... class function GetDefaultName: string; ... end; Eine Klassenmethode kann sowohl auf einem Objekt als auch auf einer Klasse operieren. Damit stehen Klassenmethoden auch dann zur Verf╨ægung, wenn keine einzige Instanz einer Klasse existiert. begin WriteLn(TConfigFile.GetDefaultName); end. Innerhalb der Implementierung einer Klassenmethode darf au╤üer auf globale Bezeichner nur auf andere Klassenmethoden zugegriffen werden. Ein Zugriff auf Felder, Eigenschaften oder gew╨ñhnliche Methoden der Klasse wird vom Compiler unterbunden. Der auch in Klassenmethoden vorhandene implizite Parameter Self enth╨ölt keine Objektreferenz, sondern eine Referenz auf die Klasse, f╨ær die die Methode tats╨öchlich aufgerufen wurde. Beim Aufruf der Klassenmethode auf einer Instanz enth╨ölt Self den tats╨öchlichen Typ dieser Instanz. Klassenmethoden sind dazu gedacht, bestimmte Prozeduren oder Funktionen einer Klasse auch dann verf╨ægbar zu machen, wenn keine Instanz der Klasse existiert. Dabei handelt es sich ╨æblicherweise um Methoden, die auf irgendeine Weise Informationen ╨æber die Klasse liefern. TObject vererbt seinen Nachkommen eine Reihe von Klassenmethoden, mit denen zum Beispiel der Name einer Klasse ermittelt werden kann, der Name des Moduls, in dem die Klasse deklariert wurde, oder die Gr╨ñ╤üe einer Instanz der Klasse. N╨öheres dazu entnehmen Sie der Beschreibung der Klasse TObject. ΓòÉΓòÉΓòÉ 1.7. Eigenschaften ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Eigenschaften ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was sind Eigenschaften? Eigenschaften sind benannte Attribute eines Objekts. Sie stellen sich dem Benutzer ╨öhnlich wie Felder dar, da sie ╨æber einen Typ verf╨ægen und ihr Wert in Form einer Zuweisung ge╨öndert wird. Die M╨ñglichkeiten von Eigenschaften gehen aber ╨æber die von Feldern weit hinaus, da es m╨ñglich ist, sowohl den lesenden als auch den schreibenden Zugriff auf die Eigenschaft einzeln zu kontrollieren oder zu verbieten. Jeder der beiden m╨ñglichen Zugriffsarten einer Eigenschaft liegt entweder ein Feld oder eine Methode zugrunde. Im ersten Fall wird der Wert der Eigenschaft aus dem Feld gelesen oder in dieses geschrieben. Im zweiten Fall wird durch das Lesen oder Schreiben der Eigenschaft implizit die Methode aufgerufen, so da╤ü durch eine einfache Zuweisung komplexe Operationen in Gang gesetzt werden k╨ñnnen. Es ist m╨ñglich, indizierte Eigenschaften zu deklarieren, die f╨ær den Benutzer die Gestalt eines Arrays haben. Da beiden Zugriffsarten einer indizierten Eigenschaft immer eine Methode zugrunde liegt, kann sie im Gegensatz zu gew╨ñhnlichen Arrays ╨æber beliebige Typen indiziert werden. Eine indizierte Eigenschaft kann zur voreingestellten Eigenschaft erkl╨ört werden, so da╤ü sich das gesamte Objekt dem Benutzer als Array darstellt. Es ist in diesem Fall nicht mehr notwendig, bei einem Zugriff auf die Eigenschaft deren Bezeichner anzugeben. F╨ær Eigenschaften, die als published gekennzeichnet werden, erzeugt der Compiler spezielle Informationen, die zur Laufzeit des Programms oder f╨ær die Zusammenarbeit mit dem Objekt-Inspektor der Sibyl-Umgebung von Bedeutung sind. Das Verhalten einer Eigenschaft in diesem Kontext kann mit einigen speziellen Schl╨æsselw╨ñrtern kontrolliert werden. Deklarieren von Eigenschaften Eigenschaften werden auf die folgende Weise deklariert: <Syntaxdiagramm: Properties> Die Deklaration einer Eigenschaft wird durch das Schl╨æsselwort property eingeleitet, gefolgt vom Bezeichner der Eigenschaft und von deren Typ. Es folgen in beliebiger Reihenfolge die Definitionen dessen, was bei lesendem oder schreibendem Zugriff auf die Eigenschaft geschieht. Die Definition der mit dem Lesen der Eigenschaft assoziierten Aktion wird eingeleitet durch das Schl╨æsselwort read, die der schreibenden Aktion analog durch write. Wenn eine der beiden Aktionen nicht definiert wird, dann existiert die entsprechende Zugriffsart nicht. Der Versuch, den Wert einer nur zum Lesen freigegebenen Eigenschaft zu ╨öndern, wird vom Compiler ebenso abgewiesen wie der Versuch, eine nur zum Schreiben freigegebene Eigenschaft in einem Ausdruck als Wert einzusetzen und damit implizit auszulesen. Sowohl das Lesen als auch das Schreiben einer Eigenschaft kann entweder mit einem Feld oder mit einer Methode assoziiert werden. Wenn das Lesen mit einem Feld assoziiert ist, dann wird beim Einsetzen der Eigenschaft in einen Ausdruck der Wert des Feldes herangezogen. Wenn das Schreiben mit einem Feld assoziiert ist, dann wird beim Zuweisen eines Wertes an die Eigenschaft dieser Wert in das entsprechende Feld geschrieben. In beiden F╨öllen mu╤ü das Feld vom gleichen Typ sein wie die Eigenschaft. Wird das Lesen einer einfachen Eigenschaft mit einer Methode assoziiert, so mu╤ü die Methode eine parameterlose Funktion sein, deren Ergebnistyp dem Typ der Eigenschaft entspricht. Der Compiler ersetzt jede Benutzung der Eigenschaft in einem Ausdruck durch einen Aufruf der Methode und bezieht das Funktionsergebnis dann in den Ausdruck ein. Wird das Schreiben einer einfachen Eigenschaft mit einer Methode assoziiert, so mu╤ü diese Methode eine Prozedur sein, deren einziger Parameter dem Typ der Eigenschaft entspricht. Der Compiler ersetzt jede ╨₧nderung des Wertes der Eigenschaft in Form einer Zuweisung durch einen Aufruf der Methode, wobei er den neuen Wert der Eigenschaft als aktuellen Parameter der Methode einsetzt. Die Methoden, die einer Eigenschaft zugrundeliegen, erhalten in Speed-Pascal ╨æblicherweise einen Bezeichner, der dem Bezeichner der Eigenschaft entspricht, wobei der lesenden Methode ein Get und der schreibenden ein Set vorangestellt wird. Sowohl Felder als auch Methoden, die einer Eigenschaft zugrundeliegen, sind meist private. Folgendes Beispiel demonstriert die Arbeit mit einer Eigenschaft, die auf zwei Methoden basiert. type TCustomer = class(TObject) private FName: PString; FID: Integer; function GetName: string; procedure SetName(const S: string); public constructor Create(Name: string); destructor Destroy; override; property ID: Integer // Auf diese Eigenschaft kann nur lesend read FID; // zugegriffen werden. Sie liefert den // Wert des Feldes FID. property Name: string // Auf diese Eigenschaft kann lesend und read GetName write SetName; // schreibend zugegriffen werden. Sie // ruft implizit die Methoden GetName // und SetName auf. end; ... function TCustomer.GetName: string; begin Result := FName^; end; procedure TCustomer.SetName(const S: string); begin AssignStr(FName, S); end; var Customer: TCustomer; begin ... with Customer do begin WriteLn('ID: ', ID); // Liest implizit das Feld FID aus. WriteLn('Name: ', Name); // Ruft implizit die Funktion GetName auf. end; ... end. Zugriff auf Eigenschaften Der Zugriff auf Eigenschaften eines Objekts entspricht aus der Sicht des Benutzers dem Zugriff auf Felder. Der Wert der Eigenschaft wird gelesen, indem die Eigenschaft in Ausdr╨æcken eingesetzt wird. Eine Eigenschaft erh╨ölt einen neuen Wert durch eine Zuweisung. Falls einer der beiden Zugriffsarten eine Methode zugrunde liegt, wird diese an den entsprechenden Stellen des Programms automatisch aufgerufen. Da Eigenschaften nicht notwendigerweise tats╨öchlich vorhandene Felder zugrundeliegen, kann der Operator @ nicht benutzt werden, um die Adresse einer Eigenschaft zu ermitteln. Ebenso ist es nicht m╨ñglich, eine Eigenschaft als aktuellen Parameter an eine Prozedur oder Funktion zu ╨æbergeben, die dort einen var-Parameter erwartet. Der Compiler f╨öngt diese Fehler ab. Indizierte Eigenschaften Eine indizierte Eigenschaft stellt sich dem Benutzer wie ein Array dar. Bei der Deklaration einer indizierten Eigenschaft wird zwischen ihrem Bezeichner und ihrem Typ in eckigen Klammern eine beliebige Liste von formalen Parametern angegeben, ╨æber die die Eigenschaft indiziert wird. Dabei ist jeder Typ erlaubt, der in der formalen Parameterliste einer Prozedur erlaubt ist; indizierte Eigenschaften sind nicht wie Arrays auf Aufz╨öhlungstypen beschr╨önkt. Die mit dem Lesen und Schreiben einer indizierten Eigenschaft assoziierten Aktionen m╨æssen Methoden sein. Sie werden auf die gleiche Weise angegeben wie bei einfachen Eigenschaften, aber sie m╨æssen besondere Bedingungen erf╨ællen: Die mit dem Lesen der Eigenschaft assoziierte Methode mu╤ü eine Funktion sein. Ihre formale Parameterliste mu╤ü der in eckigen Klammern angegebenen Parameterliste der Eigenschaft entsprechen. Der Typ des Funktionsergebnisses mu╤ü dem Typ der Eigenschaft entsprechen. Die mit dem Schreiben der Eigenschaft assoziierte Methode mu╤ü eine Prozedur sein. Ihre formale Parameterliste mu╤ü der in eckigen Klammern angegebenen Parameterliste der Eigenschaft entsprechen. Zus╨ötzlich mu╤ü sie einen weiteren Parameter am Ende ihrer Parameterliste besitzen, dessen Typ mit dem Typ der Eigenschaft ╨æbereinstimmt. type TStrings = class(TObject) protecedD function GetValue(const Name: string): string; virtual; procedure SetValue(const Name, Value: string); virtual; ... public property Values[const Name: string]: string read GetValue write SetValue; end; ... var MyStrings: TStrings; begin ... MyStrings.Values['Compiler'] := 'Speed-Pascal/2 Version 2.0'; WriteLn(MyStrings.Values['Compiler']); ... end. Indizierte Eigenschaften d╨ærfen nicht als published gekennzeichnet werden, weil der Compiler f╨ær sie keine Laufzeitinformationen erzeugen kann. Voreingestellte Eigenschaften Es ist m╨ñglich, eine indizierte Eigenschaft zur voreingestellten Eigenschaft der Klasse zu erkl╨ören. Dies geschieht durch Anh╨öngen des Schl╨æsselwortes default an die Deklaration der Eigenschaft. Auf eine voreingestellte Eigenschaft kann zugegriffen werden, ohne da╤ü der Bezeichner der Eigenschaft angegeben werden mu╤ü. Der gew╨ænschte Index der Eigenschaft folgt in eckigen Klammern und ohne Punkt unmittelbar auf den Bezeichner der Instanzvariablen. Damit stellt sich dem Benutzer das gesamte Objekt wie ein Array dar. Er kann jedoch weiterhin auf alle Komponenten des Objektes ╨æber deren Bezeichner zugreifen. type TStrings = class(TObject) protected function Get(Index: LongInt): string; virtual; abstract; procedure Put(Index: LongInt; const S: string); virtual; abstract; ... public property Strings[Index: LongInt]: string read Get write Put; default; ... end; ... var MyStrings: TStrings; begin ... MyStrings[1] := 'Speed-Pascal/2 Version 2.0'; WriteLn(MyStrings[1]); ... end. Eine Klasse kann nur eine voreingestellte Eigenschaft besitzen. Die Voreinstellung einer Eigenschaft vererbt sich an Nachfahren, so da╤ü die Eigenschaft auch dort voreingestellt ist und bleibt. Auch die Sichtbarkeit einer voreingestellten Eigenschaft kann in Nachfahren nicht ge╨öndert werden. Beachten Sie, da╤ü der Angabe von default zum Festlegen einer voreingestellten Eigenschaft ein Semikolon vorangeht, im Gegensatz zum Festlegen des Standardwertes einer Eigenschaft im Objekt-Inspektor, der ebenfalls mit dem Schl╨æsselwort default, aber ohne Semikolon angegeben wird. Gemeinsame Zugriffsmethoden Das Schl╨æsselwort index wird derzeit nicht unterst╨ætzt. Eigenschaften und Laufzeitinformationen Die Schl╨æsselw╨ñrter default, nodefault und stored werden derzeit nicht unterst╨ætzt. ΓòÉΓòÉΓòÉ 1.8. Metaklassen ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Metaklassen ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was sind Metaklassen? Eine Metaklasse ist ein Datentyp, dessen Werte Klassen sind. ╨₧hnlich wie eine Klasse einen Typ definiert, der Objektreferenzen aufnehmen kann, kann eine Variable vom Typ einer Metaklasse Referenzen auf Klassen enthalten. Deshalb werden Metaklassen auch als Klassenreferenztypen bezeichnet. Der Wertebereich einer Metaklasse umfa╤üt die Klasse, f╨ær die sie deklariert wurde, und alle deren Nachfahren, insbesondere auch jene, die erst zu einem sp╨öteren Zeitpunkt deklariert werden. Einer Variablen vom Typ einer Metaklasse k╨ñnnen also genau die Klassen als Werte zugewiesen werden, die mit der Klasse zuweisungskompatibel sind, f╨ær die die Metaklasse deklariert wurde. Metaklassen k╨ñnnen ╨æberall dort im Programm eingesetzt werden, wo auch direkt mit Klassen operiert wird. Das betrifft insbesondere den Aufruf von Klassenmethoden, das Pr╨æfen und Wandeln von Typen mit den Operatoren is und as, sowie das polymorphe Konstruieren von Objekten. In allen F╨öllen mu╤ü die tats╨öchliche Klasse nicht bereits zur Zeit der Compilierung feststehen, sondern es wird die Klasse benutzt, die zur Laufzeit als Wert der Variablen vorgefunden wird. Deklarieren von Metaklassen Metaklassen werden auf die folgende Weise deklariert: <Syntaxdiagramm: Metaclasses> Eine Metaklasse wird mit den Schl╨æsselw╨ñrtern class of deklariert. Die Klasse, zu der die Metaklasse geh╨ñrt, mu╤ü bereits deklariert sein, zumindestens mit einer forward-Deklaration. type TVehicle = class ... end; TVehicleClass = class of TVehicle; Die Unit System deklariert bereits eine Metaklasse TClass als class of TObject. Benutzen von Metaklassen Variablen vom Typ einer Metaklasse k╨ñnnen als Werte alle Klassen aufnehmen, die mit der Klasse, f╨ær die die Metaklasse deklariert wurde, zuweisungskompatibel sind. Zus╨ötzlich kann einer solchen Variablen der Wert nil zugewiesen werden, um anzudeuten, da╤ü die Variable momentan keine g╨æltige Klasse referenziert. type TVehicle = class(TObject); ... end; TShip = class(TVehicle) ... end; TVehicleClass = class of TVehicle; var AllowedVehicles: TVehicleClass; begin ... AllowedVehicles := TVehicle; ... AllowedVehicles := TShip; ... end. Variablen vom Typ einer Metaklasse k╨ñnnen ╨æberall dort im Programm eingesetzt werden, wo auch direkt mit Klassen operiert wird. Insbesondere k╨ñnnen sie auf der rechten Seite eines der Operatoren is und as auftauchen, bei Aufruf von Klassenmethoden und beim Konstruieren von Objekten. Metaklassen und Klassenoperatoren Metaklassen k╨ñnnen auf der rechten Seite eines Ausdrucks benutzt werden, der mit den Operatoren is und as gebildet wird. Es gelten dabei prinzipiell die gleichen Regeln wie bei der direkten Ang Metaklassen und Klassenmethoden Metaklassen k╨ñnnen benutzt werden, um eine Klassenmethode aufzurufen. Der entsprechende Variablenbezeichner wird dabei gefolgt von einem Punkt vor den Methodenbezeichner gesetzt, analog zum Aufruf der Methode ╨æber einen Klassenbezeichner. Der tats╨öchliche Typ der Klasse steht dann nicht bereits zur Zeit der Compilierung fest, sondern wird erst zur Laufzeit der Variablen entnommen. Es wird die Klassenmethode aufgerufen, die dem tats╨öchlichen Wert der Klassenreferenz entsricht. Achten Sie darauf, da╤ü Klassenmethoden, die Sie auf diese Weise benutzen wollen, als virtuell gekennzeichnet sind. Ansonsten findet die Bindung wie gewohnt bereits zur Zeit der Compilierung statt. Es wird dann stets die Methode der Klasse aufgerufen, zu der die Metaklasse der Variablen deklariert wurde. Metaklassen und Konstruktoren Metaklassen k╨ñnnen beim Aufruf eines Konstruktors zum Erzeugen eines neuen Objekts benutzt werden. Bedingung daf╨ær ist, da╤ü die Zuweisungsvariante des Konstruktoraufrufes gew╨öhlt wird, da die einfache Variante nur die Angabe einer Instanzvariablen, nicht aber einer Klasse erlaubt. Diese Art des Aufrufes von Konstruktoren erm╨ñglicht das polymorphe Konstruieren von Objekten, also von Objekten, deren tats╨öchlicher Typ nicht bereits zur Zeit der Compilierung feststeht. Die Klasse, von der die neue Instanz erzeugt wird, wird zur Laufzeit der Variablen entnommen. Achten Sie darauf, da╤ü Konstruktoren, die Sie zum polymorphen Konstruieren von Objekten benutzen wollen, als virtuell gekennzeichnet sind. Ansonsten findet die Bindung wie gewohnt bereits zur Zeit der Compilierung statt. Es wird dann stets eine Instanz der Klasse erzeugt, zu der die Metaklasse der Variablen deklariert wurde. type TVehicle = class constructor Create; virtual; end; TShip = class(TVehicle) constructor Create; override; end; TVehicleClass = class of TVehicle; var VehicleType: TVehicleClass; MyVehicle: TVehicle; begin ... VehicleType := TShip; MyVehicle := TVehicleType.Create; ... end. ΓòÉΓòÉΓòÉ 1.9. Vordefinierte Klassen ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Vordefinierte Klassen ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ TObject und TClass Die in der Unit System deklarierte Klasse TObject ist die Basis der Objekthierarchie von Speed-Pascal. TObject besitzt rudiment╨öre Konstruktoren und Destruktoren sowie eine Reihe von Methoden, die f╨ær die Zusammenarbeit von Objekten mit der Sibyl-Umgebung wichtig sind. TObject ist letztlich Vorfahr jeder anderen Klasse. Wenn bei der Deklaration einer neuen Klasse nicht explizit ein Vorfahr angegeben wird, dann nimmt der Compiler TObject als Vorfahren an. Damit ist sichergestellt, da╤ü alle Objekte auf eine gemeinsame Basis zur╨æckgreifen k╨ñnnen. TClass ist die Metaklasse von TObject. Da alle anderen Klassen aufgrund ihrer Abstammung zuweisungskompatibel zu TObject sind, kann eine Variable vom Typ TClass als Werte s╨ömtliche Klassen aufnehmen, die jemals mit Speed-Pascal deklariert werden. Deklaration von TObject und TClass Die Klasse TObject ist zusammen mit ihrer Metaklasse TClass in der Unit System auf die folgende Weise deklariert: type TObject = CLASS; TClass = CLASS OF TObject; TObject = CLASS CONSTRUCTOR Create; DESTRUCTOR Destroy; VIRTUAL; PROCEDURE Free; CLASS FUNCTION NewInstance: TObject; VIRTUAL; PROCEDURE FreeInstance; VIRTUAL; CLASS FUNCTION InitInstance(Instance: Pointer): TObject; CLASS FUNCTION ClassType: TClass; CLASS FUNCTION ClassName: STRING; CLASS FUNCTION ClassUnit: STRING; CLASS FUNCTION ClassParent: TClass; CLASS FUNCTION GetClassInfo: POINTER; CLASS FUNCTION InstanceSize: LONGWORD; CLASS FUNCTION InheritsFrom(AClass: TClass): BOOLEAN; PROCEDURE DefaultHandler(VAR Message); VIRTUAL; PROCEDURE DefaultFrameHandler(VAR Message); VIRTUAL; PROCEDURE Dispatch(VAR Message); PROCEDURE DispatchCommand(VAR Message;Command:LONGWORD); PROCEDURE FrameDispatch(VAR Message); CLASS FUNCTION MethodAddress(CONST Name: STRING): POINTER; CLASS FUNCTION MethodName(Address: POINTER): STRING; FUNCTION FieldAddress(Name: STRING): POINTER; END; Methoden von TObject Viele Methoden von TObject werden entweder intern vom Laufzeitsystem ben╨ñtigt oder dienen zum Austausch von Informationen mit der visuellen Entwicklungsumgebung Sybil und der SPCC-Bibliothek. Eine Reihe von Methoden, unter anderem Konstruktor, Destruktor und die Methoden zur Botschaftsverarbeitung, k╨ñnnen und sollen vom Benutzer verwendet werden. CONSTRUCTOR Create; Der Konstruktor Create erzeugt eine neue, leere Instanz von TObject und f╨ællt sie durch einen Aufruf von InitInstance mit Nullbytes. In Nachfahren von TObject m╨æssen Sie den Konstruktor mit hoher Wahrscheinlichkeit ╨æberschreiben, um zus╨ötzliche Felder des Objektes korrekt zu initialisieren. Wenn bei der Initialisierung alle Felder auf Null gesetzt werden, oder die neue Klasse keine Felder besitzt, dann kann auch der Konstruktor von TObject diese Aufgabe ╨æbernehmen. DESTRUCTOR Destroy; VIRTUAL; Der Destruktor Destroy zerst╨ñrt die Instanz und gibt den von ihr belegten Speicher auf dem Heap frei. Wenn in einem Nachfahren von TObject keine weiteren Aktionen zum Zerst╨ñren einer Instanz notwendig sind, dann kann der Destruktor von TObject auch als Destruktor f╨ær diese Klasse benutzt werden. Wenn die Klasse komplexe Unterstrukturen besitzt, die aufger╨öumt werden m╨æssen, dann ben╨ñtigt die Klasse einen eigenen Destruktor. Es wird empfohlen, da╤ü jede Klasse, die einen Destruktor ben╨ñtigt, Destroy prinzipiell als parameterlosen Destruktor beibeh╨ölt und mittels override ╨æberschreibt. PROCEDURE Free; Die Methode Free pr╨æft eine Instanz auf nil und ruft genau dann den Destruktor Destroy auf, wenn der Wert der Instanz nicht nil ist, die Variable also ein g╨æltiges Objekt referenziert. Benutzen Sie Free, um mehr Sicherheit beim Zerst╨ñren eines Objektes zu erhalten. Ein direkter Aufruf eines Destruktors auf einer Instanzvariablen, die nil enth╨ölt, bricht das Programm mit einem Laufzeitfehler ab. Die Verwendung von Free verhindert diesen Fehler. CLASS FUNCTION NewInstance: TObject; VIRTUAL; Diese Methode wird derzeit nicht verwendet. PROCEDURE FreeInstance; VIRTUAL; Diese Methode wird derzeit nicht verwendet. CLASS FUNCTION InitInstance(Instance: Pointer): TObject; Die Klassenmethode InitInstance f╨ællt die ╨æbergebene Objektinstanz mit Nullbytes, wodurch alle ihre Felder zur╨æckgesetzt werden. Die Methode wird beim Erzeugen eines neuen Objektes vom Konstruktor Create aufgerufen. CLASS FUNCTION ClassType: TClass; Die Klassenmethode ClassType liefert tats╨öchlichen Typ einer Klasse oder einer Klassenreferenz. Wird die Methode auf einem Objekt aufgerufen, dann ist dies die tats╨öchliche Klasse des Objekts zur Laufzeit. CLASS FUNCTION ClassName: STRING; Die Klassenmethode ClassName liefert den Namen einer Klasse. Wird die Methode auf einem Objekt aufgerufen, dann ist dies der Name der tats╨öchlichen Klasse des Objekts zur Laufzeit. Der Name wird komplett in Gro╤übuchstaben zur╨æckgegeben. CLASS FUNCTION ClassUnit: STRING; Die Klassenmethode ClassUnit liefert den Namen des Moduls, in dem eine Klasse deklariert wurde. CLASS FUNCTION ClassParent: TClass; Die Klassenmethode ClassParent liefert den tats╨öchlichen Typ des unmittelbaren Vorfahren einer Klasse oder einer Klassenreferenz zur╨æck. Wird die Methode auf einem Objekt aufgerufen, dann ist dies der Vorfahre der tats╨öchlichen Klasse des Objekts. CLASS FUNCTION GetClassInfo: POINTER; Die Klassenmethode GetClassInfo liefert einen Zeiger auf interne Informationen ╨æber die Klasse. Achtung: Bei Borland Delphi hei╤üt diese Klassenmethode ClassInfo. Sie wurde in Speed-Pascal umbenannt, da das OS/2-API bereits eine Funktion mit dem gleichen Namen bereitstellt. CLASS FUNCTION InstanceSize: LONGWORD; Die Klassenmethode InstanceSize liefert die Gr╨ñ╤üe einer Instanz einer Klasse. CLASS FUNCTION InheritsFrom(AClass: TClass): BOOLEAN; Die Klassenmethode InheritsFrom pr╨æft, ob die Klasse, auf der die Methode aufgerufen wird, ein direkter oder indirekter Nachfahre von AClass ist. Sie gibt entsprechend True oder False zur╨æck. PROCEDURE Dispatch(VAR Message); Die Methode Dispatch dient zum Verteilen von Nachrichten an botschaftsverarbeitende Methoden. Dispatch sucht die zur Identifikation der Nachricht passende Methode heraus und ruft diese auf. Existiert weder in der tats╨öchlichen Klasse des Objekts noch in einem beliebigen Vorfahren eine Methode, die die Nachricht behandeln kann, dann wird die Methode DefaultHandler aufgerufen, die eine Standardbehandlung der Nachricht durchf╨æhrt. PROCEDURE DispatchCommand(VAR Message;Command Die Methode DispatchCommand dient zum Verteilen von Nachrichten des Typs WM_COMMAND an botschaftsverarbeitende Methoden. DispatchCommand sucht die zur Identifikation der Nachricht passende Methode heraus und ruft diese auf. Existiert weder in der tats╨öchlichen Klasse des Objekts noch in einem beliebigen Vorfahren eine Methode, die die Nachricht behandeln kann, dann wird die Methode DefaultHandler aufgerufen, die eine Standardbehandlung der Nachricht durchf╨æhrt. PROCEDURE FrameDispatch(VAR Message); Die Methode FrameDispatch dient zum Verteilen von Nachrichten an botschaftsverarbeitende Methoden. Im Gegensatz zu Dispatch wird FrameDispatch f╨ær Nachrichten benutzt, die an das Rahmenfenster eines Bildschirmobjektes gehen sollen. FrameDispatch f╨ær sucht die zur Identifikation der Nachricht passende Methode heraus und ruft diese auf. Existiert weder in der tats╨öchlichen Klasse des Objekts noch in einem beliebigen Vorfahren eine Methode, die die Nachricht behandeln kann, dann wird die Methode DefaultFrameHandler aufgerufen, die eine Standardbehandlung der Nachricht durchf╨æhrt. PROCEDURE DefaultHandler(VAR Message); VIRTUAL; Die Methode DefaultHandler wird von Dispatch aufgerufen, wenn keine Methode zur Behandlung einer bestimmten Botschaft gefunden werden konnte. DefaultHandler tut nichts, wird aber von graphischen Bildschirmelementen derart ╨æberschrieben, da╤ü eine Routine des Betriebssystems aufgerufen wird, die eine Standardbehandlung der Nachricht durchf╨æhrt. PROCEDURE DefaultFrameHandler(VAR Message); VIRTUAL; Die Methode DefaultFrameHandler wird von FrameDispatch aufgerufen, wenn keine Methode zur Behandlung einer bestimmten Botschaft gefunden werden konnte. DefaultFrameHandler tut nichts, wird aber von graphischen Bildschirmelementen derart ╨æberschrieben, da╤ü eine Routine des Betriebssystems aufgerufen wird, die eine Standardbehandlung der Nachricht durchf╨æhrt. CLASS FUNCTION MethodAddress(CONST Name: STRING): POINTER; Die Klassenmethode MethodAddress ermittelt die Einsprungadresse einer Methode anhand von deren Namen. CLASS FUNCTION MethodName(Address: POINTER): STRING; Die Klassenmethode MethodName ermittelt den Namen einer Methode anhand ihrer Einsprungadresse. FUNCTION FieldAddress(Name: STRING): POINTER; Die Methode FieldAddress liefert die Adresse eines Feldes anhand von dessen Namen. ΓòÉΓòÉΓòÉ 1.10. Exceptions ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Exceptions ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Was sind Exceptions? Exceptions sind ein Hilfsmittel zur Behandlung von Ausnahmesituationen in Programmen, insbesondere zur Fehlerbehandlung. Wenn eine Exception ausgel╨ñst wird, verzweigt das Programm sofort zu einem Exception-Handler, der auf den Fehler reagieren kann. Existiert kein solcher Exception-Handler dann wird das Programm mit einer Fehlermeldung abgebrochen. Durch die Benutzung von Exceptions wird der normale Kontrollflu╤ü des Programms vom Kontrollflu╤ü f╨ær Fehlerf╨ölle getrennt, wodurch das Programm besser strukturiert und leichter zu warten wird. Exceptions sind Objekte. Neue Exceptions k╨ñnnen von der Vererbung Gebrauch machen, wodurch sich eine baumartige Hierarchie von Exceptions ergibt. Von dieser Struktur profitieren Exception-Handler, indem sie viele spezielle Exceptions, die einen gemeinsamen Vorfahren besitzen, gleichzeitig behandeln. Als Objekte k╨ñnnen Exceptions au╤üerdem beliebige weitere Komponenten besitzen, zum Beispiel Felder f╨ær zus╨ötzliche Informationen, die beim Ausl╨ñsen der Exception gef╨ællt werden. Auch von diesen Informationen kann der Exception-Handler Gebrauch machen, etwa indem eine detaillierte Fehlermeldung angezeigt wird. Deklarieren von Exceptions Die Deklaration einer Exception entspricht der Deklaration einer Klasse, da Exceptions Objekte sind. Exceptions sollten, m╨æssen aber nicht unbedingt von der vordefinierten Klasse Exception oder einer ihrer Nachfahren abstammen. In sehr vielen F╨öllen ist nur die Art des aufgetretenen Fehlers relevant. Diese findet sich dank der zur Laufzeit verf╨ægbaren Typinformationen bereits in der Klasse der Exception wieder. Deshalb werden Exceptions meist sehr einfach deklariert: type EMyException = class(Exception); Es ist in Speed-Pascal ╨æblich, die Bezeichner von Exceptions stets mit dem Buchstaben 'E' zu beginnen. Genau wie gew╨ñhnliche Klassen k╨ñnnen auch Exceptions durch geschickte Ausnutzung der Vererbung hierarchisch strukturiert werden. Die vordefinierten Exceptions unterteilen sich zum Beispiel in Prozessorfehler, Speicherfehler, Ein- / Ausgabefehler und mathematische Fehler bei Integer- und Flie╤ükommaoperationen. Dieses System sollten Sie auch bei neuen Exceptions beibehalten, da es ╨æbersichtlicher ist und die Implementierung von Exception-Handlern erleichtert. Wenn Sie eine Reihe von Exceptions f╨ær einen neuen Anwendungsfall oder f╨ær eine neue Klasse deklarieren, dann tun sie dies, indem Sie zuerst eine Basis-Exception einf╨æhren, von der Sie die weiteren ableiten. type ENetworkError = class(Exception); EWrongUserName = class(ENetworkError); EWrongPassword = class(ENetworkError); Es ist m╨ñglich, einer Exception beliebige Komponenten in Form von Feldern, Methoden oder Eigenschaften hinzuzuf╨ægen. Diese Komponenten, meist werden es Felder mit detaillierten Fehlerinformationen sein, k╨ñnnen dann vom Exception-Handler benutzt werden. Die Basisklasse Exception besitzt bereits Felder zur Aufnahme einer Fehlermeldung und einer Fehleradresse. Die Exceptions, die sich mit Ein- / Ausgabefehlern besch╨öftigen, f╨ægen ein Feld mit dem Fehlercode der fehlgeschlagenen Operation hinzu. type EInOutError = class(Exception) ErrorCode: Integer; end; Achtung: Im Gegensatz zu Borland Delphi m╨æssen Sie nicht die zus╨ötzliche Unit SysUtils einbinden, um die Fehlerbehandlung ╨æber Exceptions zu aktivieren. S╨ömtliche Fehler des Laufzeitsystems werden bereits ╨æber Exceptions abgewickelt. Der Basistyp Exception ist in der Unit System deklariert. Ausl╨ñsen von Exceptions Eine Exception wird durch das Schl╨æsselwort raise und die Angabe einer Exception-Instanz ausgel╨ñst. Diese Instanz kann und wird meistens genau an dieser Stelle durch einen Konstruktor-Aufruf erzeugt. Es ist aber durchaus m╨ñglich, wenngleich meist ╨æberfl╨æssig, die Instanz vorher zu erzeugen. <Syntaxdiagramm: Raise> Der Konstruktor von Exception erwartet als Parameter einen String. Sie k╨ñnnen darin beim Ausl╨ñsen der Exception eine Fehlermeldung angeben. Sollte das Programm mangels eines passenden Exception-Handlers abgebrochen werden, gibt es zuvor diese Meldung aus. if Password <> 'top secret' then raise EWrongPassword.Create('Illegal password.'); Achtung: Im Unterschied zu Borland Delphi ist es derzeit nicht m╨ñglich, eine Fehleradresse mit Hilfe des Schl╨æsselwortes at anzugeben. Als Fehleradresse wird stets die Adresse innerhalb des Codesegmentes angenommen, an der die Exception ausgel╨ñst wurde. Behandeln von Exceptions Wenn Sie nicht wollen, da╤ü Ihr Programm beim Auftreten einer Exception mit einer Fehlermeldung abbricht, dann m╨æssen Sie auf die Exception reagieren. Dazu ╨æberwachen Sie kritische Codesequenzen und f╨ægen ihnen einen Exception-Block hinzu. Der Exception-Block enth╨ölt Code, der nur im Fehlerfall ausgef╨æhrt werden soll. Er kann einen einen oder mehrere Exception-Handler bereitstellen, die Fehler innerhalb der ╨æberwachten Codesequenz behandeln. Wenn innerhalb des ╨æberwachten Abschnitts eine Exception ausgel╨ñst wird, tritt sofort der Exception-Block in Aktion. Wird der ╨æberwachte Abschnitt fehlerfrei beendet, wird die Ausf╨æhrung hinter dem Exception-Block wiederaufgenommen. Bei verschachtelten ╨æberwachten Codesequenzen genie╤üt stets der Exception-Block die h╨ñchste Priorit╨öt, der zur innersten ╨æberwachten Sequenz geh╨ñrt. Behandelt er eine aufgetretene Exception nicht, wird sie nach au╤üen durchgereicht. ╨¬berwachte Codesequenzen und Exception-Handler <Syntaxdiagramm: Try_Except> Eine Anweisungsfolge, die von den Schl╨æsselw╨ñrtern try..except eingeschlossen wird, ist eine ╨æberwachte Codesequenz. Wenn innerhalb dieser Codesequenz eine Exception ausgel╨ñst wird, dann verzweigt das Programm unmittelbar zu der Anweisungsfolge, die sich zwischen den Schl╨æsselw╨ñrtern except..end befindet und als Exception-Block bezeichnet wird. Dieser Exception-Block kann einen oder mehrere Exception-Handler bereitstellen, um bestimmte Fehler zu behandeln. Er kann auch einen universellen Exception-Handler beinhalten, der jede Art von Fehler behandelt. try /*Die folgenden Anweisungen sind kritisch. Wenn die Datei nicht ge╨ñffnet werden kann, oder sich w╨öhrend des Lesens Probleme einstellen, dann wird eine Exception ausgel╨ñst. Das Programm verzweigt dann unmittelbar zum EXCEPT..END- Block, der den Fehler behandeln solle. */ Assign(F, 'c:\userdata\report.txt'); Reset(F); ... Close(F); except ... end; Der Exception-Block kann auf die Fehlerbedingung reagieren, mu╤ü dies aber nicht tun. Ob ein Exception-Block auf eine bestimmte Art von Exception reagiert, kann vom Programmierer festgelegt werden. Im allgemeinsten Fall werden die Exceptions nicht weiter differenziert. Es ergibt sich ein universeller Exception-Handler, der jede Art von Exception behandelt. except /*Dies ist ein universeller Exception-Handler. Der Code zwischen EXCEPT..END wird in jedem Fehlerfall ausgef╨æhrt. Der Fehler wird dadurch beseitigt. */ WriteLn('Unbekannter Fehler beim Lesen der Datei.'); end; Durch Einsatz der Schl╨æsselw╨ñrter on..do kann die Arbeit des Exception-Blockes auf eine oder mehrere Arten von Exceptions eingeschr╨önkt werden. Jedes on..do definiert einen Handler f╨ær eine bestimmte Klasse von Exceptions. except /*Dieser Exception-Handler bearbeitet nur Fehler vom Typ 'EFileNotFound'. Alle weiteren Exceptions reicht er an die n╨öchsth╨ñhere Ebene weiter. */ on EFileNotFound do WriteLn('Die angegebene Datei existiert nicht.'); end; Es k╨ñnnen mit on..do beliebig viele Exception-Handler angegeben werden. Das Laufzeitsystem geht sie im Fehlerfall der Reihe nach durch. Sobald ein passender Exception-Handler gefunden wird, wird dessen Code ausgef╨æhrt, und der Fehler wird beseitigt. Es wird niemals mehr als ein Exception-Handler ausgef╨æhrt. Beachten Sie, da╤ü ein Exception-Handler auch immer alle Nachfahren der Klasse behandelt, f╨ær die er installiert wurde. Deshalb sollten speziellere Exception-Handler in der Liste stets weiter vorn stehen, da sie sonst niemals erreicht werden. Ausgehend davon, da╤ü alle Exceptions, die im Zusammenhang mit Dateioperationen stehen, einen gemeinsamen Vorfahren EInOutError besitzen, k╨ñnnte eine Fehlerbehandlung etwa wie folgt aussehen: except /*Diese Exception-Handler bearbeiten eine Reihe von Fehlern. Die spezielleren Handler stehen dabei weiter vorn, die allgemeineren am Ende der Liste. */ on EFileNotFound do WriteLn('Die angegebene Datei existiert nicht.'); on EAccessDenied do WriteLn('Zugriff auf die Datei verweigert.'); on EInvalidFilename do WriteLn('Ung╨æltiger Dateiname.'); on EInOutError do WriteLn('Ein-/Ausgabefehler beim Lesen der Datei.'); end; Bei Angabe einer Liste von Exception-Handlern mit on..do ist es au╤üerdem m╨ñglich, im Anschlu╤ü an den letzten Exception-Handler mit else einen weiteren anzugeben, der alle Exceptions behandelt, auf die nicht bereits einer der speziellen Handler reagiert hat. except /*Diese Exception-Handler bearbeiten eine Reihe von Fehlern. Die spezielleren Handler stehen dabei weiter vorn, die allgemeineren am Ende der Liste. Fehler, die nicht mit der Ein-/Ausgabeoperation in Zusammenhang stehen, werden durch den ELSE-Teil behandelt. */ on EFileNotFound do WriteLn('Die angegebene Datei existiert nicht.'); on EAccessDenied do WriteLn('Zugriff auf die Datei verweigert.'); on EInvalidFilename do WriteLn('Ung╨æltiger Dateiname.'); on EInOutError do WriteLn('Ein-/Ausgabefehler beim Lesen der Datei.'); else WriteLn('Unbekannter Fehler beim Lesen der Datei.'); end; Wird eine Exception innerhalb des Exception-Blocks behandelt, dann wird sie beseitigt, und die Ausf╨æhrung wird unmittelbar hinter dem except..end-Block wiederaufgenommen. Behandelt keiner der Exception-Handler den aufgetretenen Fehler, dann bleibt die Exception bestehen. Der eingebaute Exception-Handler von Speed-Pascal tritt in Aktion und beendet das Programm mit einer Fehlermeldung, es sei denn, der gesamte Abschnitt befindet sich innerhalb einer weiteren mittels try..except ╨æberwachten Codesequenz. Tritt innerhalb der ╨æberwachten Codesequenz gar keine Exception auf, dann verzweigt das Programm nach Beendigung des try..except-Blockes unmittelbar hinter das Ende des Exception-Blockes. Es besteht in diesem Fall keine Veranlassung, die Fehlerbehandlung aufzurufen. Beachten Sie, da╤ü es sich bei der Verzweigung im Fehlerfall um einen unmittelbaren Sprung handelt, nicht um einen Prozeduraufruf. Der Stack wird soweit aufger╨öumt, da╤ü er sich im gleichen Zustand befindet wie beim Betreten der ╨æberwachten Codesequenz. Danach wird die Exception-Behandlung angesprungen. Nach der Behandlung der Exception kann kein R╨æcksprung an die Fehleradresse mehr stattfinden. Stattdessen wird die Ausf╨æhrung hinter dem except..end-Block wiederaufgenommen. Geschachtelte Exception-Handler Es ist m╨ñglich, ╨æberwachte Codesequenzen zu schachteln. Dies kann entweder direkt durch Schachtelung von try..except-Anweisungen geschehen oder indirekt dadurch, da╤ü innerhalb der ╨æberwachten Codesequenz aufgerufene Prozeduren oder Funktionen selbst lokal Codesequenzen ╨æberwachen. In beiden F╨öllen werden die zugeh╨ñrigen except..end-Bl╨ñcke auf eine Art Stapel gelegt, wobei sich der zum zuletzt betretenen try..except-Block geh╨ñrende zuoberst befindet. Tritt eine Exception auf, so wird zum obersten auf dem Stapel befindlichen except..end-Block verzweigt. Dieser geh╨ñrt zu genau der ╨æberwachten Codesequenz, die zuletzt betreten und noch nicht wieder beendet wurde. Falls hier ein Exception-Handler existiert, der die aufgetretene Exception behandelt, findet die Behandlung statt, und die Exception wird gel╨ñscht. Die Ausf╨æhrung wird hinter dem except..end-Block wiederaufgenommen. Behandelt keiner der Exception-Handler die aufgetretene Exception, so wird der except..end-Block vom Stapel abger╨öumt, und es wird zum n╨öchsten except..end-Block verzeigt. Dies geschieht solange, bis ein Exception-Handler den aufgetretenen Fehler behandelt. Existiert kein solcher Exception-Handler, tritt die eingebaute Fehlerbehandlung von Speed-Pascal in Aktion. Das Programm wird abgebrochen. Ausl╨ñsen von Exceptions im Exception-Handler Bei Schachtelung von ╨æberwachten Codesequenzen kann es sinnvoll sein, lokal auf den Fehler zu reagieren, aber die Fehlerbedingung bestehen zu lassen, damit die n╨öchsth╨ñhere Ebene auch darauf reagieren kann. In diesem Fall kann innerhalb des except..end-Blockes durch Einsatz von raise ohne jeden weiteren Parameter daf╨ær gesorgt werden, da╤ü die aufgetretene Exception unmittelbar wieder ausgel╨ñst wird. Der except..end-Block wird vom Stapel abger╨öumt, und es wird so verfahren, als w╨öre die Exception nicht behandelt worden. Diese spezielle syntaktische Variante von raise kann nur innerhalb eines Exception-Handlers benutzt werden. Es ist auch m╨ñglich, mittels der normalen Syntax von raise eine andere Exception innerhalb eines except..end-Blockes auszul╨ñsen. Wird diese Exception nicht lokal innerhalb des except..end-Blockes behandelt, dann verdr╨öngt sie die urspr╨ængliche Exception. Diese wird gel╨ñscht, der except..end-Block wird vom Stapel abger╨öumt, und die Behandlung der neuen Exception wird an die n╨öchsth╨ñhere Ebene verwiesen. Dies kann manchmal sinnvoll sein, wenn mehrere lokal auftretende Exceptions abgefangen und in einen gemeinsamen Typ von Exception umgewandelt werden sollen, der von der n╨öchsth╨ñheren Ebene behandelt wird. Es kann aber auch zu unerw╨ænschten Ergebnissen f╨æhren, wenn nicht beachtet wird, da╤ü innerhalb eines - m╨ñglicherweise sehr komplexen - Exception-Handlers wiederum Fehler auftreten k╨ñnnen. In diesem Fall sollten Sie den kritischen Bereich innerhalb des Exception-Handlers wiederum in einen try..except-Block mit anschlie╤üendem except..end-Block einschlie╤üen. Exceptions, die innerhalb des inneren Exception-Handlers nicht bearbeitet werden, verdr╨öngen die Exception des ╨öu╤üeren Handlers und werden an die n╨öchsth╨ñhere Ebene verwiesen. Zugriff auf die Exception-Instanz Es ist m╨ñglich, innerhalb eines Exception-Handlers auf die Exception-Instanz zuzugreifen. Das ist sinnvoll, wenn die aufgetretene Exception zus╨ötzliche Informationen enth╨ölt, die vom Handler ausgewertet werden sollen. Zum Zugriff auf die Exception-Instanz kann einem durch on..do eingeleiteten Exception-Handler ein Bezeichner gefolgt von einem Doppelpunkt vorangestellt werden. Innerhalb dieses einen Exception-Handlers steht dann unter dem angegebenen Bezeichner die Instanz der aufgetretenen Exception zur Verf╨ægung. Der Typ des Bezeichners entspricht der Exception-Klasse, die der Handler bearbeitet, ist also eine passende Objektreferenz. Das folgende Beispiel soll die M╨ñglichkeiten verdeutlichen. Die Exception-Klasse EInOutError und deren Nachfahren besitzen ein Feld ErrorCode, das den Fehlercode des aufgetretenen Fehlers enth╨ölt. Diesen Fehlercode k╨ñnnte sich ein Exception-Handler zunutze machen. try Assign(F, 'c:\userdata\report.txt'); Reset(F); ... Close(F); except on E: EInOutError do WriteLn('Ein-/Ausgabefehler ', E.ErrorCode, ' beim Lesen der Datei.'); else WriteLn('Unbekannter Fehler beim Lesen der Datei.'); end; Beachten Sie, da╤ü es nicht n╨ñtig ist, die Variable mittels var zu deklarieren. Der Bezeichner wird an der entsprechenden Stelle generiert und ist nur innerhalb des zugeh╨ñrigen Exception-Handlers g╨æltig. Achtung: Sie haben ╨æber den Bezeichner auch Zugriff auf alle Methoden der Instanz. Gehen Sie sehr vorsichtig mit dieser M╨ñglichkeit um. Versuchen Sie insbesondere niemals, die Exception-Instanz mittels Destroy oder Free selbst zu l╨ñschen. Das ist Aufgabe des Exception-Handlers. Der Versuch, dies 'von Hand' zu erledigen, w╨ærde das Laufzeitsystem derart durcheinander bringen, da╤ü das Programm mit hoher Wahrscheinlichkeit abst╨ærzt. Sch╨ætzen von Resourcen Wenn innerhalb einer fehleranf╨ölligen Codesequenz Resourcen belegt werden, dann ist es notwendig, diese auch beim Auftreten einer Exception wieder freigeben zu k╨ñnnen. Anderenfalls gehen die Resourcen m╨ñglicherweise dauerhaft verloren, da das Auftreten der Exception einen direkten Sprung zum Exception-Handler zufolge hat. Die Anweisungen, die die Benutzung der Resource abschlie╤üen und diese freigeben, werden im Fehlerfall gar nicht erreicht. Die try..finally-Anweisung dient dazu, die Freigabe von Resourcen auch im Fehlerfall zu garantieren. <Syntaxdiagramm: Try_Finally> Um zu garantieren, da╤ü eine bestimmte Codesequenz auch beim Auftreten einer Exception ausgef╨æhrt wird, gehen Sie wie folgt vor: Setzen Sie die Anweisungen, die die Resource allokieren, vor den try..finally-Block. Schlie╤üen Sie die Arbeit mit der Resource in den try..finally-Block ein. Schlie╤üen Sie die Anweisungen zum Freigeben der Resource in den finally..end-Block ein. /*Zuerst wird die Resource allokiert. In diesem Fall wird versucht, eine Datei zu ╨ñffnen. */ Assign(F, 'c:\userdata\report.txt'); Reset(F); try // Lesen der Datei. M╨ñglicherweise treten hier Fehler auf. ... finally // Die Datei soll in jedem Fall geschlossen werden. Close(F); end; Wird innerhalb des try..finally-Blocks eines Exception ausgel╨ñst, verzweigt das Programm zuerst zum finally..end-Block. Wenn dieser beendet ist, wird die Exception an den zust╨öndigen Exception-Handler weitergereicht, falls ein solcher existiert. Beachten Sie, da╤ü die Exception innerhalb eines finally..end-Abschnittes nicht behandelt wird. Dieser Bereich ist kein Exception-Handler, er garantiert nur die Ausf╨æhrung einer Reihe von Anweisungen unabh╨öngig davon, ob ein Fehler auftritt oder nicht. Um auf den Fehler zu reagieren, mu╤ü der gesamte Abschnitt gesch╨ætzt und mit einem Exception-Handler versehen werden. Es ist nicht m╨ñglich, finally und except zu kombinieren, etwa derart, da╤ü der except-Block auf den finally-Block folgt. try /*Zuerst wird die Resource allokiert. In diesem Fall wird versucht, eine Datei zu ╨ñffnen. */ Assign(F, 'c:\userdata\report.txt'); Reset(F); try // Lesen der Datei. M╨ñglicherweise treten hier Fehler auf. ... finally // Die Datei soll in jedem Fall geschlossen werden. Close(F); end; except WriteLn('Es trat ein Fehler beim Lesen der Datei auf.'); end; Es ist m╨ñglich, try..finally-Bl╨ñcke ineinander zu schachteln. Es ist dann auf jeder Ebene sichergestellt, da╤ü die Anweisungen zwischen finally..end ausgef╨æhrt werden, bevor zur n╨öchsth╨ñheren Ebene verzweigt wird. Achtung: Falls innerhalb eines finally..end-Blockes eine Exception ausgel╨ñst wird, die dort nicht lokal behandelt wird, verdr╨öngt sie die urspr╨ængliche Exception und verzeigt zum n╨öchsten zust╨öndigen Exception-Handler. Das Verhalten ist zwar definiert, aber es ist nicht empfehlenswert, da╤ü Sie davon Gebrauch machen. Stellen Sie stattdessen sicher, da╤ü Exceptions, die in finally..end-Bl╨ñcken auftreten, auch dort behandelt werden. Exceptions und Objekte Exceptions k╨ñnnen ohne Einschr╨önkung innerhalb von Objektmethoden verwendet werden. Es gibt jedoch eine Besonderheit zu beachten. Wenn innerhalb eines Konstruktor-Aufrufes eine Exception auftritt, die dort nicht behandelt wird, dann wird zuerst der Destruktor aufgerufen, bevor zum m╨ñglicherweise vorhandenen Exception-Handler verzweigt wird. Damit verhalten sich Konstruktoren exakt so, als w╨ören sie auf die folgende Weise implementiert: constructor TMyClass.Create; begin try // Gew╨ænschte Anweisungen zwischen BEGIN und END except Destroy; raise; end; end; Aufgrund dieses Verhaltens ist es wichtig, da╤ü ein Destruktor auch mit nicht vollst╨öndig initialisierten Objekten umzugehen wei╤ü, denn er kann theoretisch von jeder beliebigen Stelle des Konstruktors aus aufgerufen werden. ΓòÉΓòÉΓòÉ 1.11. Vordefinierte Exceptions ΓòÉΓòÉΓòÉ ΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓûä Vordefinierte Exceptions ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇ Basisklasse Exception S╨ömtliche Laufzeitfehler von Speed-Pascal werden ╨æber Exceptions abgewickelt. Dazu sind in der Unit System bereits eine Reihe von Exceptions vordefiniert. Exception = class(TObject) public constructor Create(const Msg: String); destructor Destroy; override; property Message: string; // lesen / schreiben property MessagePtr: PString; // nur lesen end; ExceptClass = class of Exception. Exception ist die Basisklasse f╨ær Ausnahmebedingungen. Von ihr sollten alle weiteren Exception-Klassen abgeleitet werden. Exception selbst wird selten ausgel╨ñst, meist werden es spezialisierte Nachkommen sein, die auf bestimmte Fehler hinweisen. Alle Exception-Klassen erben von Exception Konstruktor, Destruktor sowie die Eigenschaft Message, die die Fehlermeldung enth╨ölt, die beim Ausl╨ñsen der Exception an den Konstruktor ╨æbergeben wird. Software-generierte Exceptions EProcessTerm = class(Exception); EProcessTerm wird vom Betriebssystem ausgel╨ñst, wenn der Proze╤ü beendet werden soll. Hardware-generierte Exceptions EProcessorException = class(Exception); EProcessorException ist der Vorfahr f╨ær weitere vom Prozessor ausgel╨ñste Exceptions. Es wird niemals EProcessorException selbst ausgel╨ñst, sondern stets ein Nachkomme, der auf eine bestimmte Ausnahmebedingung hinweist. Im Unterschied zu EFault weist EProcessorException nicht unbedingt auf einen Fehler hin, denn die Nachfahren EBreakpint und ESingleStep dienen zum Debuggen eines Programms. EFault = class(EProcessorException); EFault ist der Vorfahr f╨ær alle vom Prozessor ausgel╨ñsten Exceptions, die auf einen Fehler hinweisen. Es wird niemals EFault ausgel╨ñst, sondern stets ein Nachkomme, der auf eine bestimmte Fehlerbedingung hinweist. Im Gegensatz zu EProcessorException weist EFault immer auf einen Fehler hin. EGPFault = class(EFault); EGPFault wird ausgel╨ñst, wenn eine allgemeine Schutzverletzung auftritt. Eine Schutzverletzung liegt vor, wenn ein Proze╤ü auf Speicherbereiche zugreift, die nicht innerhalb seines Adre╤üraums liegen. Meist deutet dieser Fehler darauf hin, da╤ü eine illegale Zeigeroperation durchgef╨æhrt wurde oder da╤ü mit einem nicht korrekt initialisierten Objekt gearbeitet wurde. EStackFault = class(EFault); EStackFault wird ausgel╨ñst, wenn nicht gen╨ægend Stackspeicher vorhanden ist, um die aktuelle Operation durchzuf╨æhren. Prozeduren und Funktionen reservieren beim Aufruf den Speicher f╨ær ihre lokalen Variablen auf dem Stack. Wenn dieser Fehler auftritt, dann teilen Sie dem Programm mehr Stackspeicher zu oder vermeiden Sie die Benutzung zu vieler lokaler Variablen, insbesondere bei Rekursion. Diese Exception kann nur auftreten, wenn die Stackpr╨æfung aktiviert ist, die Operation also im Modus $S+ compiliert wird. EPageFault = class(EFault); EPageFault wird vom Prozessor ausgel╨ñst, wenn ein Seitenfehler auftritt. Ein Seitenfehler liegt vor, wenn der Proze╤ü auf eine Speicherseite zugreifen will, die momentan ausgelagert ist. Dieser Fehler sollte normalerweise nicht auftreten, da sich das Betriebssystem um die Verwaltung des physikalischen und virtuellen Speichers k╨æmmert und die entsprechende Seite automatisch wieder einlagert. EInvalidOpCode = class(EFault); EInvalidOpCode wird vom Prozessor ausgel╨ñst, wenn dieser auf eine illegale Maschineninstruktion trifft. EBreakpoint = class(EProcessorException); EBreakpoint wird vom Prozessor ausgel╨ñst, wenn dieser auf einen Breakpoint trifft. ESingleStep = class(EProcessorException); ESingleStep wird vom Prozessor nach jedem durchgef╨æhrten Befehl ausgel╨ñst, wenn das Programm im Einzelschrittmodus abgearbeitet wird. Exceptions bei Speicher-Operationen EOutOfMemory = class(Exception); EOutOfMemory wird ausgel╨ñst, wenn eine angeforderte Menge Speicher nicht mehr auf dem Heap zur Verf╨ægung steht. EInvalidPointer = class(Exception); EInvalidPointer wird ausgel╨ñst, wenn ein Programm versucht, einen Speicherbereich zu deallokieren, der nicht zuvor allokiert wurde oder bereits freigegeben ist. EInvalidHeap = class(Exception); EInvalidHeap wird ausgel╨ñst, wenn der Heapbereich der Applikation besch╨ödigt ist. Dies kann vorkommen, wenn die Applikation durch fehlerhafte Zeigeroperationen Speicherbereiche ╨æberschreibt, die f╨ær die Heapverwaltung wichtig sind. Exceptions bei Ein- / Ausgabeoperationen EInOutError = class(Exception) public ErrorCode: Integer; end; EInOutError ist der Vorfahr f╨ær eine Reihe von Exceptions, die auf Ein- / Ausgabe-Fehler hinweisen. Alle Exceptions dieser Art besitzen ein zus╨ötzliches Feld, das den Fehlercode aufnehmen kann, der bei der Operation aufgetreten ist. Damit diese Exception und ihre Nachfahren auftreten k╨ñnnen, mu╤ü die Ein- / Ausgabe-╨¬berpr╨æfung aktiviert sein, die entsprechende Operation mu╤ü also im Modus $I+ compiliert werden. EAccessDenied = class(EInOutError); EAccessDenied wird ausgel╨ñst, wenn das ╨⌐ffnen einer Datei fehlschl╨ögt, weil entweder die Attribute der Datei ein ╨⌐ffnen zum Schreiben nicht erlauben, oder weil die Datei bereits von einem anderen Proze╤ü exklusiv ge╨ñffnet wurde. EDiskFull = class(EInOutError); EDiskFull wird ausgel╨ñst, wenn die Diskette oder Festplatte, auf die der Proze╤ü schreiben will, voll ist. EEndOfFile = class(EInOutError); EEndOfFile wird ausgel╨ñst, wenn der Proze╤ü versucht, ╨æber das Ende einer Datei hinaus zu lesen. EFileNotFound = class(EInOutError); EFileNotFound wird ausgel╨ñst, wenn der Proze╤ü versucht, eine Datei zu ╨ñffnen, die nicht existiert. EInvalidFileName = class(EInOutError); EInvalidFileName wird ausgel╨ñst, wenn ein illegaler Dateiname benutzt wird, der zum Beispiel zu lang ist oder Sonderzeichen enth╨ölt, die nicht Teil eines Dateinamens sein d╨ærfen. EInvalidInput = class(EInOutError); EInvalidInput wird ausgel╨ñst, wenn der Benutzer des Programms eine ung╨æltige Eingabe macht. ETooManyOpenFiles = class(EInOutError); ETooManyOpenFiles wird ausgel╨ñst, wenn zu viele Dateien gleichzeitig ge╨ñffnet sind. Wenn der Fehler auftritt, erh╨ñhen Sie die entsprechende Einstellung des Betriebssystems, um mehr gleichzeitig ge╨ñffnete Dateien zu erlauben. Mathematische Exceptions bei Integer-Operationen EIntError = class(Exception); EIntError ist der gemeinsame Vorfahr einer Reihe von Exceptions, die auf Fehler bei mathematischen Operationen mit Integer-Werten hinweisen. EDivByZero = class(EIntError); EDivByZero wird ausgel╨ñst, wenn eine Division durch Null versucht wird. ERangeError = class(EIntError); ERangeError wird ausgel╨ñst, wenn f╨ær das Ergebnis einer mathematischen Operation eine Bereichspr╨æfung fehlschl╨ögt. Damit diese Exception auftreten kann, mu╤ü die Operation im Modus $R+ compiliert werden. EIntOverflow = class(EIntError); EIntOverflow wird ausgel╨ñst, wenn das Ergebnis einer mathematischen Operation einen ╨¬berlauf produziert hat. Damit dieser Fehler auftreten kann, mu╤ü die Operation im Modus $Q+ compiliert werden. Mathematische Exceptions bei Flie╤ükomma-Operationen EMathError = class(Exception); EIntError ist der gemeinsame Vorfahr einer Reihe von Exceptions, die auf Fehler bei mathematischen Operationen mit Integer-Werten hinweisen. EInvalidOp = class(EMathError); EInvalidOp wird ausgel╨ñst, wenn eine ung╨æltige mathematisch Operation versucht wird, z.B. das Ziehen der Wurzel aus einer negativen Zahl. EZeroDivide = class(EMathError); EZeroDivide wird ausgel╨ñst, wenn eine Division durch Null versucht wird. EOverflow = class(EMathError); EOverflow wird ausgel╨ñst, wenn das Ergebnis einer mathematischen Operation einen ╨¬berlauf produziert hat. EUnderflow = class(EMathError); EUnderflow wird ausgel╨ñst, wenn das Ergebnis einer mathematischen Operation so klein ist, da╤ü es mit der Pr╨özision der Ergebnisvariablen nicht mehr dargestellt werden kann. Dieser Fehler tritt normalerweise nicht auf. Stattdessen liefert Speed-Pascal den Wert Null als Ergebnis zur╨æck. Durch ╨₧ndern des Kontrollwortes des mathematischen Koprozessors kann das Ausl╨ñsen dieser Exception jedoch erm╨ñglicht werden. Exceptions bei Typwandlungen EInvalidCast = class(Exception); EInvalidCast wird ausgel╨ñst, wenn eine Typwandlung mit Hilfe des Operators as fehlschl╨ögt. EConvertError = class(Exception); EConvertError wird bei einer Reihe von Konvertierungsfunktionen ausgel╨ñst, wenn der Quellwert ung╨æltig ist.