Dans Sui Move, les objets peuvent posséder d'autres objets, tout comme les objets des comptes. Cela ouvre la voie à de nouveaux modèles de conception (et à quelques pièges) pour les développeurs. Dans ce guide, je vais décomposer les concepts d'objets parent-enfant dans Sui Move en quatre parties : 1.Introduction aux concepts parent-enfant dans Sui Move 2.Mécanique de contrôle d'accès et de réception des objets 3.Gestion intermodule des enfants avec public_receive 4.** Logique captivante et modèle de reçu de retour**

À la fin, vous comprendrez comment imbriquer des objets, récupérer des objets enfants via transfer : :receive, gérer les enfants entre les modules avec public_receive et même créer des objets liés à l'âme qui renvoient en boomerang à leur propriétaire.

Introduction aux concepts parent-enfant dans Sui Move

###Que sont les objets pour parents et enfants ?

Dans Sui, chaque objet possède un identifiant unique et un propriétaire. Généralementle propriétaire est une adresse(comme le compte d'un utilisateur), mais le propriétaire peut aussi être un autre objet.

Si l'objet A possède l'objet B, nous appelons A le parent et B l'enfant. L'enfant est propriétaire d'un objet plutôt que d'une adresse.

Transfert vers des objets : Sui ne fait pas réellement la distinction entre une adresse et un identifiant d'objet. Les deux ne sont que des identifiants de 32 octets. Cela signifie que vous pouvez transférer un objet vers l'identifiant d'un autre objet de la même manière que vous le feriez vers l'adresse d'un utilisateur. Lorsque vous procédez ainsi, vous imbriquez effectivement un objet dans un objet parent. L'environnement d'exécution de Sui définit le champ du propriétaire de l'enfant sur l'identifiant du parent (au lieu d'une adresse)

Alors pourquoi est-ce cool ?

Parce que l'enfant conserve son propre identifiant unique et existe indépendamment dans le stockage, mais qu'il est désormais lié au parent. C'est comme si vous offriez à votre ami un objet de collection unique à conserver dans son casier : l'objet de collection conserve son identifiant et peut être suivi, mais le casier de votre ami est désormais répertorié comme son propriétaire.

Il est important de faire la distinction entreObjets uniques, objets imbriqués et objets enfants :

-**Objet unique (appartenant à l'adresse) :**Un objet normal appartenant à une adresse (par exemple, le compte d'un utilisateur). C'est le cas par défaut : pensez aux NFT, aux pièces de monnaie, etc., qui se trouvent directement dans le portefeuille de l'utilisateur. Chacune possède un identifiant unique et est de niveau supérieur en termes de stockage. -Objet imbriqué (encapsulé) :Un objet qui est stocké dans les données d'un autre objet (par exemple, sous forme de champ dans une structure). Dans ce cas, l'objet interne est encapsulé etpasne constitue pas une entité de niveau supérieur distincte. Il n'apparaît pas par son identifiant dans le stockage global car il fait partie du contenu en octets du parent. En Sui, si vous placez un objet sous forme de champ dans un autre sans manipulation particulière, il est encapsulé. -**Objet enfant (appartenant à un objet) :**Un objet qui appartient à un autre objet mais qui n'est pas directement encapsulé dans ses champs. L'enfant reste un objet de premier niveau distinct en stockage (avec son propre identifiant et ses propres données), et l'identifiant du parent est enregistré en tant que propriétaire dans les métadonnées de l'enfant. Cela signifie que vous pouvez interroger l'enfant ou y accéder par son identifiant (avec les autorisations appropriées). Il n'est pas physiquement intégré au contenu du parent, il est simplement détenu de manière logique. Pour utiliser notre analogie, c'est comme si vous aviez donné à votre ami votre objet de collection à conserver : il est toujours étiqueté et traçable individuellement, simplement rangé dans son casier.

L'avantage de fabriquer un objet pour enfant (par transfert) au lieu de l'emballer est que la carte d'identité de l'enfant reste accessible de l'extérieur. Par exemple, les explorateurs ou les portefeuilles peuvent répertorier un objet enfant par identifiant, alors qu'un objet encapsulé est invisible en dehors de son parent.

Les objets pour enfants conservent également des identifiants stables même lorsqu'ils passent d'un propriétaire à l'autre ou s'imbriquent dans des parents différents. C'est idéal pour des choses comme l'inventaire en chaîne ou les modèles « portefeuille dans un portefeuille », où vous souhaitez qu'un objet contenant puisse contenir de nombreux objets que d'autres peuvent encore référencer individuellement

Propriété et accès : si un objet appartient à un autre objet, seul le propriétaire du parent peut généralement accéder à l'enfant ou l'utiliser. Il s'agit d'une forme d'autorisation dynamique. Par exemple, si Alice possède un objet parent P et que P possède l'enfant C, alors seule Alice (ou les transactions signées par Alice) peut manipuler C. Sui applique cette règle de sorte que posséder un parent revient à détenir les clés de tous ses enfants 🔑.

Peut-être connaissez-vous :

La fonction de transfert vers un objet de Sui nous donne essentiellement la propriété d'un objet semblable à un arbre. Un parent peut avoir de nombreux enfants (et ces enfants peuvent avoir leurs propres enfants, en formant une hiérarchie). Cela se fait en traitant les identifiants d'objets comme des adresses pour les transferts. Nous avons :

-Objets appartenant à l'adresse(objets uniques normaux), -Objets appartenant à un objet(objets enfants, toujours de niveau supérieur mais liés à un parent), -Objets encapsulés(imbriqués dans les données d'un autre objet, pas de niveau supérieur).

Dans les prochains articles, nous verrons comment récupérer ou interagir avec des objets enfants (puisqu'ils ne sont pas directement accessibles comme ceux dont l'adresse est propriétaire) et comment appliquer des règles les concernant.