zurück nächster hoch Titel Inhalt

Struktur und Aufbau

Xclasses stellt ein hierarchisches System von Klassen zur Verfügung. Daraus läßt sich jede Art von Programm entwickeln, die eine grafische Benutzeroberfläche nutzen. Abbildung -: Objektbaum eines Programms In der obersten Stufe jedes Xclasses-Programm steht das Programm bzw. dessen (Haupt-) Fenster. Jedes Programm kann durchaus aus mehreren Hauptfenstern bestehen, wobei jedes eine eigene Hierarchie darstellt, die im Programm zusammenläuft.

Jedes Fenster besteht aus Gruppen, meist erst einmal eine Gruppe, die dann wiederum aus Gruppen besteht. In den Gruppen können nun weitere Gruppen oder Gadgets (z.B. Buttons) enthalten sein. Technisch ist es sogar möglich (und wird sogar genutzt), daß ein Gadget Gruppen enthält.

Aus Sicht des Programmierers sind Gruppen und Gadgets das Gleiche da Gruppen von Gadgets abgeleitet sind und eine spezielle Form von Gadget darstellen. Durch diese Ableitung bieten Gruppen natürlich mehr Funktionen als Gadget, so daß Objekte, die Gadgets verlangen auch Gruppen zugeteilt bekommen können. Jedoch müssen Objekte, die Gruppen verlangen auch Gruppen bekommen. Das klingt jetzt erstmal recht "gaga", aber eigentlich ganz logisch: Gadgets sind die unterste Stufe, d.h. es können auch Gruppen statt dessen übergeben werden. Gruppen stehen eine Stufe höher, so daß Gadgets nicht übergeben werden können.

Jedem Xclasses-Objekt kann ein Name gegeben werden. Standardmäßig ist dies der Name der Klasse, jedoch kann und sollte man diesen ändern, z.B. hat ein "Ok"-Button besser den Namen "okbutton" statt nur "button". Außerdem ermöglicht dies eine bessere Fehlersuche, da Xclasses einen konkreten Namen ausgeben kann, z.B. wenn eine Berechnung zu unbrauchbaren Ergebnissen führt; und zudem kann so eine Verwendung von speziellen X-Resourcen ermöglicht werden.

Jedes Xclasses-Objekt besitzt meist ein anderes Objekt als Elternobjekt (außer dem aller, aller obersten Objekt, der Klasse XCprogramm oder aber auch eine Gruppe ohne appwindow als Fenster). Somit besitzt ein Objekt über seinen Namen und sein Elternobjekt und wiederum dessen Elternobjekte einen eindeutigen Namen. Dieser besteht aus einen Pfad aller Namen, jeweils durch einen Punkt (".") getrennt. Im Beispiel oben hätte z.B. das Gadget unten links den Namen "programm.fenster.gruppe.gruppe.gadget". Nur hätte dort das Gadget daneben den selben "eindeutigen" Namen, somit dürfte der Grund, weshalb man Objekten sinnvolle Namen geben soll klar sein - außer man möchte auf diese Funktionalität der Namen verzichten (bei einfachen Projekten schonmal verständlich).

Xclasses-Programme lassen sich durch diese Namensvergabe nach drei Methoden aufbauen:

1. Alle nötigen Klassen in einem Modul global definieren: Dies ist der schnellste Weg und man kann sich die Namensvergabe sparen. Andererseits werden so gerade große Projekte schnell unübersichtlich, da sonst leicht zu große Module entstehen.

2. Die Klassen werden lokal in einer Funktion erzeugt. Diese Funktion darf jedoch erst verlassen werden, wenn man die Objekte nicht mehr benötigt (z.B. beim Programmende oder beim Schliessen eines Fensters). Alternativ kann man die Klassen in diesem Fall aber auch als statisch ("static") deklarieren. Allerdings kann einem dabei schonmal ein "guter Informatiker" an den Hals springen.

3. Die Klassen werden in einer Funktion dynamisch erzeugt (per "new"). In einer anderen Funktion können sie dann später mit einem Funktionsaufruf über den Objektebaum wieder gelöscht werden. Dies ist der eleganteste Weg und entspricht dem objekteorientierten Gedanken am besten, da so die Erzeuger-Funktion merhmals aufgerufen werden kann und so z.B. ein Fenster für verschiedene Zwecke mehrfach erzeugt werden kann.

Zu allen drei Methoden existiert in Kapitel "Alles zusammen in einem Programm", 94 ein Beispiel.


zurück nächster hoch Titel Inhalt