Im allgemeinen, in der objekt-orientierten Programmierung, ist eine Klasse eine abstrakte Definition von (1.) Daten-Typen und (2.) Aktionen, die auf diese Daten angewendet werden k”nnen. Die letzteren sind auch als Objekt-Methoden bekannt.
W„hrend Klassen den Objekt-Typ nur auf eine abstrakte Art beschreiben, werden die Objekte, die wirklich in einem Programm existieren, Instanzen einer bestimmten Klasse genannt.
Nehmen wir beispielsweise ein WPS-Programm-Objekt: Jedes Programm ist eine Instanz der Klasse WPProgram, die von der WPS definiert wurde. Die (1.) Daten des Programm-Objekts wrden, neben anderen, die mit ihm verbundene ausfhrbare Datei sein (z.B. "CMD.EXE"), w„hrend (2.) Methoden (die auf diese Daten angewendet werden k”nnten) das Starten des Programms (durch Doppelklick oder den Meneintrag "™ffnen") oder das Žndern der Einstellungen im entsprechenden Meneintrag w„ren. Obwohl man die Methoden nicht "sehen" kann, werden sie trotzdem intern immer verwendet, wenn die WPS irgendetwas tut. Wenn Sie Erfahrung mit dem Begriff haben, kann man Methoden mehr oder weniger als "Application Programmer's Interface" (API, auf deutsch etwa: Programmentwicklerschnittstelle) fr ein Objekt beschreiben. Falls Sie in REXX programmieren: Jedes Mal, wenn Sie eines dieser Objekt-Einstellungs-Strings verwenden, um die Daten eines Objektes zu ver„ndern, wenden Sie eine Methode auf ein Objekt an.
Da Methoden fr jede Klasse einzeln definiert werden, h„ngt die Anzahl der Methoden, die auf ein Objekt angewendet werden k”nnen, von der Klasse des Objekts ab. Ich habe sie nicht gez„hlt, aber schon WPObject, die fundamentalste WPS-Klasse, definiert mehr als 100 Methoden.
Was die objekt-orientierte Programmierung so flexibel (und popul„r) macht, ist die M”glichkeit der Definition von Verwandschaften zwischen Objekten. Um dies zu verstehen, sind folgende zwei Konzepte hilfreich:
Die Arbeitsoberfl„chen-Klasse ("WPDesktop" genannt) wird von der Ordner-Klasse ("WPFolder" genannt) abgeleitet. D.h. daá die Arbeitsoberfl„che nur eine spezielle Sorte Ordner ist.
Grunds„tzlich gesehen hat die Arbeitsoberfl„che alle M”glichkeiten eines normalen Ordners: Man kann andere Objekte hineintun, ihren Inhalt sortieren, eine Baum- oder Detail-Ansicht ”ffnen usw. Aber zus„tzlich bietet WPDesktop einige Dinge mehr: Das Kontextmen enth„lt mehr Eintr„ge (wie "Systemabschluá" und "Systemkonfiguration"), sein Einstellungsnotizbuch hat ein paar Reiter mehr usw. Offensichtlich erbt die Arbeitsoberfl„che Ordner-Charakteristiken, aber fgt auch neue Eigenschaften hinzu. Auf der anderen Seite werden einige Ordner-Eigenschaften unterdrckt: Beispielsweise kann man die aktive Arbeitsoberfl„che nicht schlieáen, und sie hat auch keine Titelzeile.
Die WPS stellt eine Ableitungsstruktur zur Verfgung, so daá alle Objekte logisch gruppiert und abh„ngig voneinander sind. Auf einer weit abstrakteren Ebene sind alle Objekt-Klassen der WPS Ableitungen einer EINZIGEN KLASSE mit Namen "WPObject", die bestimmte Funktionen bietet, die alle WPS-Objekte brauchen: haupts„chlich die M”glichkeit, Kontextmens, Einstellungsnotizbcher und derartige Dinge anzuzeigen. Dies ist typisch fr objekt-orientierte Programmierung; solch eine globale Ursprungsklasse wird auch "Wurzelklasse" einer "Klassenhierarchie" genannt.
Auf WPObject baut die WPS einen kompletten Baum von Klassen auf, der als WPS-Klassenhierarchie bekannt ist. Sie k”nnen unter dem Reiter "WPS-Klassen" in &xwp;s Objekt "WPS-Klassenliste" einen Blick darauf werfen.
Eine solche Klassenhierarchie hat den Vorteil, daá man nur die Eigenschaften
der Wurzelklasse „ndern muá, um alle davon abgeleiteten Klassen
ebenfalls zu „ndern. (Der Nachteil aus Sicht eines Programmierers ist,
daá man sehr genau die Zusammenh„nge der verschiedenen Klassen
und Methoden analysieren muá, um eine solche Klassenhierarchie aufzubauen.
H„ufig passiert es, daá die Planung nicht ganz optimal war. Aber
wenn die Hierarchie erst einmal gut durchdacht ist - Dank an IBM, daá
es im Falle der WPS so ist -, sind die Vorteile berragend.)
Nur als ein Beispiel m”chte ich den Punkt "Hilfe" erw„hnen, der im Kontextmen eines jeden Objekts vorhanden ist. Durch Auswahl von "Erweiterte Hilfe" wird die wpDisplayHelp-Methode des Objekts aufgerufen. Diese Methode wird von der WPS Wurzel-Klasse ("WPObject") bereitgestellt, so daá alle WPS-Objekte die Hilfe anzeigen k”nnen: Der &os2;-Hilfemanager wird initialisiert, das Hilfefenster wird dargestellt usw. Die anzuzeigende Hilfeseite wird aber von beinahe jeder WPS-Klasse ge„ndert (dem Konzept der Polymorphie folgend). Also bringt die Auswahl von "Hilfe" aus dem Kontextmen eines Ordners etwas anderes zum Vorschein als etwa bei der Auswahl aus dem Men eines Programm-Objekts.
Dieses System funktioniert nur, weil die WPS IBMs eigenes System Object Model (SOM) benutzt, ein komplexes System, das objekt-orientierte Programmierschnittstellen sogar zwischen verschiedenen Codemodulen und sprachenunabh„ngig bietet. SOM ist so m„chtig, da Klassen zur Laufzeit anstatt zur Kompilierzeit instantiiert und aufrechterhalten werden.
Hier kommt brigens die WPS-Klassenliste ins Spiel: Wenn die WPS hochgefahren wird, erzeugt sie alle Klassen (die, in SOM, auch Objekte sind, aber das ist eine sehr komplexe Angelegenheit) und richtet die Verwandtschaften erst zu diesem Zeitpunkt ein. Nur deswegen ist es m”glich, Klassen ohne IBM, die die Orginale erschaffen hat, zu modifizieren.
Meiner Meinung nach ist dies immer noch etwas, das &os2; in der heutigen
Computer-Welt einzigartig macht. Mit der Zeit sind alle anderen Vorteile
als Alleinstellungsmerkmale verschwunden, wie z.B. das verl„áliche
Multitasking (Linux ist darin auch wirklich gut), aber die Benutzerschnittstelle
wurde bisher noch von keinem anderen Betriebssystem, das ich kenne, erreicht.
Besonders nicht von Windows 95.