Zusammenfassung

Es ist unzweifelhaft, daß Oberon eine problemgerechte Modularisierung unterstützt, die es erlaubt, die Sichtbarkeitsgrenzen entsprechend den vorgestellten Anforderungen zu ziehen. So können Datentypen, die zusammengehören, auch zusammen in einem Modul deklariert werden; private Datenstrukturen bleiben privat und blähen nicht die gesamte Klassenhierarchie auf. Darüber hinaus erlaubt das Konzept der Typerweiterung die Trennung eines Records in einzelne private Bereiche, für die verschiedene Module verantwortlich sind.

Oberon unterstützt objekt-orientierte Konzepte nicht unmittelbar. Zunächst existiert eine feste Bindung zwischen einer Schnittstelle und der zugehörigen Implementierung. Allerdings lassen sich bei Verwendung entsprechender Konventionen alle zuvor zusammengefaßten wichtigen Konzepte realisieren. Obwohl die dynamisch zu bindenden Operationen durch die Verwendung von Prozedurvariablen realisiert werden, läßt sich das gleiche Maß an Sicherheit erreichen wie bei den Sprachen, die dies direkt unterstützen:

• Die Prozedurvariablen sind nicht öffentlich zugänglich. Damit können sie weder anderen Objekten zugeordnet werden, noch ist es möglich, sie für ein Objekt zu ändern. Entsprechend ist auch sichergestellt, daß die dynamisch gebundenen Operationen auch genau das Objekt vorfinden, das sie erwarten.
• Bei der Technik mit den Schnittstellenrecords und dem Konzept der Fähigkeiten ist Klarheit darüber gegeben, welche Operationen zur Verfügung stehen. Bei den nicht optionalen Operationen ist dies statisch festgelegt.
• Durch Erledigungsvermerke bei den Aufträgen läßt sich sicherstellen, daß der Aufrufer nachprüfen kann, ob eine Operation bearbeitet worden ist.

Die Konventionen sind nur im Bereich der Abstraktionen und zum Teil bei den Implementierungen relevant. Für Klienten besteht praktisch kein Unterschied zwischen Oberon und klassischen objekt-orientierten Sprachen. Die einzige Ausnahme ist durch die Notation gegeben, da das Objekt nur ein normaler Parameter einer normalen Prozedur ist. Dies erhöht allerdings die Lesbarkeit durch die Angabe des Modulnamens und wurde aus ähnlichen Gründen auch bei Trellis/Owl verwendet.

Während sich mit den vorgestellten Konventionen auch außergewöhnliche Techniken (Delegationen, Farbenproblem) realisieren lassen, so ist die durch die klassischen objekt-orientierten Sprachen favorisierte Technik des inkrementellen Überdefinierens nur mit unverhältnismäßig hohen Aufwand realisierbar. Hierfür ist jedoch eine zweite Hierarchie von aufeinander aufbauenden Implementierungen geeigneter, die auf normalen Importbeziehungen beruht. Dies wird zudem von Oberon in idealer Weise unterstützt.

Bemerkenswert ist, daß die Techniken von Oberon über die klassischer objekt-orientierter Sprachen hinausgehen. So sind Delegationen realisierbar und mit der Unterstützung einiger Bibliotheksmodule auch dynamisch hinzufügbare Erweiterungen, Persistenz und die Übermittlung von Operationen an andere Prozesse.

Wäre man bestrebt, alle besprochenen Konzepte zu integralen Bestandteilen einer Programmiersprache zu machen, führt dies zu einer völligen Überladung (siehe C++). Statt einer ökonomischen Sprache, die sich nur aus wenigen Grundkonzepten zusammensetzt, wäre dann eine Sprache notwendig, bei der neben der Komplexität der einzelnen Konzepte noch die kombinatorische Komplexität hinzukommen würde. Dies wurde in Oberon sorgfältig vermieden. So stehen Klassen nicht in Konflikt zu Modulen und Methoden nicht in Konflikt zu Prozedurtypen.

Somit stellt Oberon einen Kompromiß dar, der einerseits einige Konventionen fordert, zum anderen jedoch damit die vorgestellten Anforderungen weit besser erfüllt als klassische objekt-orientierte Programmiersprachen. Vergleichbare Konzepte finden sich nur in hybriden Sprachen (z.B. Modula-3), die jedoch gegen das gängige Design-Konzept für Programmiersprachen verstoßen, nachdem es für ein Problem maximal ein Sprachkonstrukt geben sollte.