Zusammenfassung

In der allgemeinsten und einfachsten Form sind Objekte nur reine Bezugspunkte, die mit beliebig vielen Abstraktionen statisch oder dynamisch verknüpft werden können und bei denen es nicht notwendigerweise eine Instanz gibt, die das gesamte Objekt mitsamt allen beteiligten Datenstrukturen kennt. Stattdessen wird ein Objekt im Laufe seines Lebens möglicherweiser einer Vielzahl von Modulen als Bezugspunkt genannt oder bekannt, von denen jedes seine sehr eingeschränkte Sicht der Dinge besitzt. Aus diesem Grund sind zahlreiche kooperative Konventionen notwendig, damit alle Operationen, die andere Parteien betreffen könnten, den Interessenten zur Kenntnis gelangen.

Grundsätzlich werden Kooperationen immer durch entsprechende Module repräsentiert, bei denen sich alle Interessenten oder Betroffenen registrieren und über die dann später Notifikationen verlaufen. In den demonstrierten Beispielen der Ulmer Oberon-Bibliothek wurde dies unter anderem bei folgenden Punkten realisiert:

• Resources verwaltet die Objekt-Zustände im Rahmen des Lebenszyklus, der insbesondere die Terminierung und die Unterbrechung der Kommunikation einschließt. Diese Kooperation erlaubt es, Speicherlecks und Hänger zu vermeiden.

• RelatedEvents erlaubt eine objekt-bezogene Ausnahmenbehandlung, bei der alle interessierten Parteien alles an Informationen über einen Ausfall erhalten können.

• Forwarders ermöglicht eine Koordinierung bei dem Aufbau von Filterketten, die eine entsprechende Ausnahmenbehandlung, die Verwaltung zusätzlicher privater Datenstrukturen und die Unterstützung sekundärer Abstraktionen ermöglicht.

• Services unterstützt sekundäre Abstraktionen, indem es Objekte mit den dafür zur Verfügung stehenden sekundären Abstraktionen und deren Implementierungen zusammenbringt.

Wenn entsprechende Kooperationsmechanismen fehlen, dann geht die Eigenschaft der Erweiterbarkeit verloren, die Ergänzungen ermöglicht, ohne bestehende Module zu verändern.