Objektorientierung ist je nach Autor mit unterschiedlichem Schwerpunkt
definiert. Unter anderem ist sie gekennzeichnet durch
* Objektidentität
* Modularisierung
* Kapselung
* Klassen
* Vererbung
* Überladung
* Klassenhierarchie
(vgl.[Hil96],[KGZ94])
In Avenue existieren Klassen in der Form, daß Objekte stets einer Klasse
angehören bzw. von einer Klasse instantiiert werden können.
Objektkomponenten können nur über ihre Objektmethoden zugegriffen
werden (Kapselung). Vorhanden sind Klassen, die derart eine Hierarchie bilden,
daß Unterklassen Methoden und Komponenten von Oberklassen geerbt haben.
Hingegen fehlt die Möglichkeit, selbst neue Klassen von bestehenden
Klassen abzuleiten. In Avenue besteht also nur eine statische, d.h. nicht mehr
veränderbare Klassenhierarchie.
Eine Modularisierung ist nur durch Aufteilung des Programms in einzelne
Avenue-Scripte möglich. Diese können einander mittels der Methode
run des Objekts av aufrufen. av ist das Programm ArcView
selbst. Die Methode run Objekts av aufrufen. av
repräsentiert das Programm ArcView selbst. Die Methode run
erhält dazu den Namen des aufzurufenden Avenue-Scripts als Parameter. Weil
ein Avenue-Script sich nicht selbst direkt oder indirekt aufrufen kann, fehlt
Rekursion.
Als weiteren Parameter muß ein aufzurufendes Avenue-Script ein
Avenue-Objekt erhalten. Da dieses auch eine Avenue-Liste sein kann, die
wiederum andere Objekte enthalten kann, sind praktisch beliebige Avenue-Objekte
als Parameter für einen Avenue-Script-Aufruf möglich.
Sehr fehlerträchtig ist die Eigenschaft Avenues, daß Variablen stets
erst zur Laufzeit an Typen gebunden werden, indem einer Variablen ein Wert
zugewiesen wird. Die Variable erhält dadurch den Typ des zugewiesenen
Wertes. Eine Typprüfung durch den Compiler etwa aufgrund von
Deklarationen findet nicht statt.
Zusammen mit dem Umstand, daß eine Avenue-Liste beliebige Avenue-Objekte
enthalten darf, gestaltet sich die Programmierung typsicherer
Parameterübergabe äußerst schwierig, da jede Typprüfung
zur Laufzeit mit Hilfe zusätzlich programmierter Prüfanweisungen
durchgeführt werden muß. Folgendes Beispiel verdeutlicht dies:
erwartet ein Avenue-Script zwei Parameter der Typen A und B,
so ist zu prüfen
* ob der eine syntaktisch mögliche Parameter des Avenue-Scripts vom Typ
Liste ist,
* ob diese Liste genau zwei Elemente enthält,
* ob das erste Element von Typ A ist und
* ob das zweite Element von Typ B ist.
Zwar beschleunigt der Verzicht auf Prüfung und Typisierung die
Prototypentwicklung, jedoch ist dieser Vorteil bei umfangreicheren
Programmierprojekten rasch wieder aufgehoben.
Die Sichtbarkeit von Variablen ist in lediglich zwei Bereiche
eingeteilt:
Der erste Bereich ist der lokale Sichtbarkeitsbereich. Variablen sind nur in
denjenigem Avenue-Script sichtbar, in dem sie zuerst einen Wert zugewiesen
bekommen haben. In einem aufgerufenen Avenue-Script sind die Variablen nicht
sichtbar, eine gleichbezeichnete Variable überdeckt dort die Variable des
aufrufenden Scripts. Ist ein Avenue-Script beendet, so gehen die Werte
verloren. Sie sind dann auch im Debugger nicht mehr sichtbar. Die Bezeichner
lokaler Variablen dürfen nicht mit einem Unterstrich "_" beginnen.
Der zweite Bereich ist der globale Sichtbarkeitsbereich. Die Bezeichner
globaler Variablen müssen mit einem Unterstrich beginnen. Sie sind in
jedem Script sichtbar, sobald sie in irgendeinem ausgeführten Script einen
Wert zugewiesen bekommen haben. Globale Variablen behalten ihren Wert auch
über die Laufzeit des zuerst gestarteten Avenue-Scripts hinaus. Er ist
dann auch im Debugger sichtbar. Soll eine globale Variable entfernt werden, so
kann ihr der besondere Wert NIL zugewiesen werden, so daß sie vom
Garbage Collector entfernt wird, weil sie dann auf keinen Wert mehr verweist.
Daneben können auch alle globalen Variablen auf einmal durch die
Anweisung ClearGlobals entfernt werden.