Delegationen und Abhängigkeiten zwischen Objekten

Bei einer Delegation reicht ein Objekt alle Operationen (in möglicherweise modifizierter Form) an ein oder ggf. mehrere andere Objekte weiter. Das delegierende Objekt wird dabei als Filter-Objekt oder Proxy bezeichnet. Delegationen sind insbesondere sinnvoll bei

• Filterungen (so eliminiert z.B. Comments alle Kommentare bei der Eingabe),
• ergänzenden Operationen (so offeriert z.B. CopyingStreams Positionierungen auf reinen Eingabeverbindungen, die das nicht unterstützen),
• Verteilern (wie z.B. Maps, das in Abhängigkeit seiner lokalen Position Operationen an eine der untergeordneten Verbindungen weiterleitet),
• Vervielfältigern (wie z.B. in dem Beispiel DribbleCollections in §2.6) und
• verteilten Systemen, da dort Objekte in anderen Adressräumen durch Proxies vertreten werden, die die Operationen zum Original-Objekt weiterleiten.

Durch Delegationen entstehen Abhängigkeiten, die den Lebenszyklus der beteiligten Objekte betreffen:

• Wenn das Objekt hinter einem Filter-Objekt terminiert, sind normalerweise Operationen auf dem Filter-Objekt nicht mehr sinnvoll. Entsprechend liegt es nahe, das Leben des Filter-Objekts in diesem Augenblick ebenfalls zu beenden.

• Wenn alle Filter-Objekte (typischerweise wohl nur ein einziges), die auf ein Objekt zeigen, terminieren und es sonst keine weiteren schwergewichtigen Verweise auf dieses Objekt gibt, ist es sinnvoll, auch in umgekehrter Richtung die Terminierung zu propagieren.

Diese Problematik wird von Resources unterstützt. Mit Hilfe der Operation Resources.DependsOn können entsprechende Abhängigkeiten deklariert werden, wobei Resources einerseits einen schwergewichtigen Verweis von dem abhängenden Objekt auf das bezogene Objekt setzt und umgekehrt dafür sorgt, daß die Terminierung des bezogenen Objekts zur Terminierung des abhängenden Objekts führt.

Ein wichtiges Problem bei Filter-Objekten ist die Berücksichtigung sekundärer Abstraktionen, da Module, die Filter-Objekte implementieren, selbst nur eine primäre Abstraktion unterstützen. Eine Lösung hierfür bietet Forwarders an, das die Registrierung von sekundären Abstraktionen ermöglicht und diese im Bedarfsfall informiert, wenn ein Filter-Objekt neu erzeugt wird.

Unterstützt werden die durch Forwarders registrierten Filter-Objekt-Ketten auch durch RelatedEvents, das in so einem Fall automatisch, Ereignisse von dem Ende der Kette an die Front bringt - also in genau umgekehrt zur Bearbeitungsreihenfolge von Operationen. Dies geschieht unabhängig von den weiteren Einstellungen, die auch eine Weiterleitung von objektbezogenen Ereignissen entlang der Aufrufkette nicht ausschließen (in diesem Fall würden sich Ereignisse in beide Richtungen ausbreiten, bis alle beteiligten Objekte sie mitbekommen haben).

Ein Problempunkt bei Delegationen kann die Lokation von Disziplinen sein. In vielen Fällen sind Module nur an einer Disziplin pro Filterkette interessiert und möchten nur ungern den Verwaltungsaufwand betreiben, der notwendig würde, wenn sie sich bei Forwarders registrieren. Hierfür gibt es IndirectDisciplines, das die gleiche Schnittstelle wie Disciplines aufweist, jedoch die gesamte Kette nach einer Disziplin absucht.