In Sui Move können Objekte andere Objekte besitzen, genau wie Accounts eigene Objekte. Das eröffnet Entwicklern neue Entwurfsmuster (und ein paar Fallstricke). In diesem Handbuch werde ich die Konzepte von über- und untergeordneten Objekten in Sui Move in vier Teile unterteilen: 1.Einführung in die Eltern-Kind-Konzepte in Sui Move 2.Objektzugriffskontrolle und Empfangsmechanik 3.Modulübergreifende Kinderverwaltung mit public_receive 4.Seelenbindende Logik und Muster für Rücksendebestätigungen

Am Ende wirst du verstehen, wie man Objekte verschachtelt, untergeordnete Objekte per transfer: :receive abruft, untergeordnete Objekte mit public_receive modulübergreifend verwaltet und sogar seelengebundene Objekte erstellt, die zu ihrem Besitzer zurückkehren.

Einführung in die Eltern-Kind-Konzepte in Sui Move

###Was sind übergeordnete und untergeordnete Objekte?

In Sui hat jedes Objekt eine eindeutige ID und einen Eigentümer. Normalerweise istder Besitzer eine Adresse(wie ein Benutzerkonto), aber der Besitzer kann auch ein anderes Objekt sein.

Wenn Objekt A Objekt B besitzt, nennen wir A das Elternteil und B das Kind. Das Kind gehört dem Objekt und nicht der Adresse.

Übertragung auf Objekte: Sui unterscheidet nicht wirklich zwischen einer Adresse und einer Objekt-ID unter der Haube — beide sind nur 32-Byte-Identifikatoren. Das bedeutet, dass Sie ein Objekt auf die ID eines anderen Objekts übertragen können, genauso wie Sie es an die Adresse eines Benutzers übertragen würden. Wenn Sie das tun, verschachteln Sie quasi ein Objekt innerhalb eines übergeordneten Objekts. Die Laufzeit von Sui setzt das Eigentümerfeld des Kindes auf die ID des Elternteils (statt auf eine Adresse)

Also warum ist das cool?

Weil das Kind seine eigene eindeutige ID behält und unabhängig im Speicher existiert, aber jetzt ist es an das Elternteil gebunden. Es ist, als ob du deinem Freund ein einzigartiges Sammlerstück gibst, das er in seinem Schließfach aufbewahren kann — das Sammlerstück behält seine ID und kann nachverfolgt werden, aber das Schließfach deines Freundes ist jetzt als Besitzer aufgeführt.

Es ist wichtig,Einzigartige Objekte von verschachtelten Objekten und untergeordneten Objekten zu unterscheiden:

-Eindeutiges Objekt (im Besitz der Adresse) :Ein reguläres Objekt, das einer Adresse gehört (z. B. ein Benutzerkonto). Dies ist der Standardfall — denken Sie an NFTs, Münzen usw., die sich direkt in der Brieftasche eines Benutzers befinden. Jedes hat eine eindeutige ID und befindet sich auf der obersten Speicherebene. -Verschachteltes (umhülltes) Objekt: Ein Objekt, das in den Daten eines anderen Objekts gespeichert wird (z. B. als Feld in einer Struktur). In diesem Fall ist das innere Objekt verpackt undnichteine separate Entität der obersten Ebene. Es wird nicht anhand seiner ID im globalen Speicher angezeigt, da es Teil des Byte-Inhalts des übergeordneten Objekts ist. Wenn Sie in Sui ein Objekt ohne besondere Behandlung als Feld in ein anderes einfügen, wird es umschlossen. -**Untergeordnetes Objekt (Object-Owned) :**Ein Objekt, das einem anderen Objekt gehört, aber nicht direkt in seine Felder eingeschlossen ist. Das untergeordnete Objekt bleibt ein separates Objekt der obersten Ebene im Speicher (mit eigener ID und eigenen Daten), und die ID des Elternteils wird in den Metadaten des Kindes als Besitzer aufgezeichnet. Das bedeutet, dass Sie das Kind anhand seiner ID abfragen oder darauf zugreifen können (mit den richtigen Berechtigungen). Es ist nicht physisch in den Inhalt der Eltern eingebettet, sondern gehört ihm nur logisch. Mit unserer Analogie ist es so, als ob du deinem Freund dein Sammlerstück zum Aufbewahren gegeben hast — es ist immer noch individuell markiert und verfolgbar, es wird nur in seinem Schließfach aufbewahrt.

Der Vorteil, ein Kind zum Objekt zu machen (per Transfer), anstatt es zu verpacken, besteht darin, dass der Ausweis des Kindes von außen zugänglich bleibt. Beispielsweise können Explorer oder Wallets ein untergeordnetes Objekt nach seiner ID auflisten, wohingegen ein umschlossenes Objekt außerhalb des übergeordneten Objekts unsichtbar ist.

Untergeordnete Objekte behalten auch dann stabile IDs bei, wenn sie zwischen Besitzern wechseln oder in verschiedenen übergeordneten Objekten verschachtelt werden. Das eignet sich hervorragend für Dinge wie Inventar auf der Kette oder Muster „Brieftasche in einer Brieftasche“, bei denen Sie möchten, dass ein Containerobjekt viele Gegenstände enthält, auf die andere immer noch einzeln verweisen können

Eigentum und Zugriff: Wenn ein Objekt einem anderen Objekt gehört, kann in der Regel nur der Besitzer des übergeordneten Objekts auf das untergeordnete Objekt zugreifen oder es verwenden. Dies ist eine Form der dynamischen Autorisierung. Wenn Alice beispielsweise ein übergeordnetes Objekt P besitzt und P das untergeordnete Objekt C besitzt, dann kann nur Alice (oder Transaktionen, die Alice signiert) C manipulieren. Sui erzwingt dies, sodass der Besitz eines übergeordneten Objekts so ist, als würde man allen untergeordneten Objekten die Schlüssel halten 🔑.

Vielleicht weißt du:

Die Funktion zum Übertragen auf ein Objekt von Sui gibt uns im Grunde genommen baumähnliches Objektbesitz. Ein Elternteil kann viele Kinder haben (und diese Kinder können ihre eigenen Kinder haben, wodurch eine Hierarchie entsteht). Dies wird erreicht, indem Objekt-IDs wie Adressen für Übertragungen behandelt werden. Wir haben:

-Adresseigene Objekte(normale eindeutige Objekte), -Objekteigene Objekte(untergeordnete Objekte, immer noch auf oberster Ebene, aber an ein übergeordnetes Objekt gebunden), -Umschlossene Objekte(verschachtelt in den Daten eines anderen Objekts, nicht auf oberster Ebene).

In den nächsten Artikeln werden wir sehen, wie man untergeordnete Objekte tatsächlich abruft oder mit ihnen interagiert (da auf sie nicht direkt zugegriffen werden kann, wie es bei adresseigenen Objekten der Fall ist) und wie man Regeln für sie durchsetzt.