Im Falle der Shards sollen die Objekte allerdings wesentlich speziellerer Natur sein, nämlich uneingeschränkt transportabel. Daher verlangen wir von vornherein Persistenz. Shards.Pot und Shards.Lid müssen also als Erweiterungen von PersistentDisciplines.Object in die Typenhierarchie eingeführt werden, und korrekte Implementierungen benötigen die obligatorischen Methoden (marshalling procedures) für PersistentObjects.
Zu beachten ist, daß es umgekehrt einen Schlüssel, der überall bzw. nirgends paßt, nicht geben kann. Ein beliebiges unbekanntes Shards.Lid-Objekt wird zwar von den meisten Kontrolleuren zurückgewiesen werden, aber es gibt keine prinzipielle Möglichkeit, ein bestimmtes Verhalten zu erzwingen.
Um das Protokoll nicht zu verletzen, soll auch das zusammengesetzte Verfahren nur einen "Topf" und einen "Deckel" als Bezugspunkte benutzen. Im ersten Fall ist dies sehr leicht möglich. Soll ein Topf mehrere verschiedene Deckel akzeptieren, braucht er nur seinerseits mehrere einfache Töpfe enthalten und deren Kontrollmethoden mit "oder" zu verknüpfen.
Der zweite Fall ist kritischer. Ein "Supertopf", der mehrere Kontrollen mit "und" verknüpft, wird vermutlich jeden gewöhnlichen Deckel zurückweisen. Um so verfahren zu können, bedarf es also auch eines "Superdeckels", der gleichzeitig von verschiedenen Töpfen akzeptiert wird. Ein Deckel hat als an diesem Verfahren nur passiv Beteiligter allerdings nicht die Möglichkeit, zu bestimmen, welche Methode auf ihn anzuwenden ist. Dieses Problem läßt sich auf der Ebene der Abstraktion lösen, wenn sie zusammengesetzte Deckel intern so verwaltet, daß externe Implementierungen davon gar nicht behelligt werden. Eine implementierende Methode wird also, auch wenn ein "Superdeckel" getestet wird, implizit nur mit "Elementardeckeln" konfrontiert, dafür aber unter Umständen mehrmals.
Es bleibt festzuhalten, daß die Möglichkeit, Deckel zu kombinieren (mit Hilfe der Funktion Shards.CombineLids) genügt, um jede Art von "und"- und "oder"-Verknüpfungen sowohl von Töpfen als auch Deckeln innerhalb des einfachen Protokolls zuzulassen.
Dieses Codebeispiel zeigt den gesamten Definitionsteil des Moduls Shards in Oberon. Zuerst werden die beiden Objekttypen Pot und Lid definiert; es folgen die Datentypen der Schnittstelle für Implementierungen (interface). Als Prozeduren treten natürlich die beiden Methoden Fits und Supply auf sowie die Initialisierungsroutine für neue Objekte, Init.
Drei Konstruktoren ebnen den Zugang zu den intern implementierten Objekttypen: CombineLids erzeugt einen "Superdeckel" aus zwei Komponenten -- da diese wiederum zusammengesetzt sein können, lassen sich auch größere Konglomerate bilden --, CreateSimplePot liefert die beiden Sorten trivialer Töpfe und CreateSomeLid einen Deckel "ohne besondere Eigenschaften".
Zu bemerken ist, daß die wahren Typen der so erzeugten Objekte, die ja Erweiterungen der abstrakten Typen sind, gar nicht exportiert werden. Hinter dieser "Geheimniskrämerei" steckt das Bestreben, der Implementierung sogar in der Frage, ob eigene Datentypen verwendet werden, größtmögliche Freiheit zuzugestehen und dadurch Abhängigkeiten zu vermeiden.
Dieses Codefragment zeigt anhand der Methode Shards.Fits, wie eine typische Aufgabenverteilung zwischen einer Methode der Abstraktion und der zugehörigen implementierenden Methode aussehen kann:
Die Kontrolle selbst wird als elementarer Vorgang betrachtet, dessen Ergebnis nüchtern als Funktionsresultat zurückzumelden ist, ohne etwa den Ablehnungsfall mit großem Lärm als Ausnahmesituation zu behandeln.