Les méthodes Go intégrées peuvent-elles accéder aux champs de structure parent ?

Les méthodes intégrées peuvent-elles accéder aux champs parents ?

Dans Go, les méthodes intégrées sont un mécanisme puissant pour la réutilisation et l'organisation du code. Cependant, une question courante se pose : les méthodes intégrées peuvent-elles accéder directement aux champs de leur structure parent ?

Contexte

Pour le contexte, supposons que vous créiez un enregistrement actif. style ORM pour Go où les méthodes CRUD courantes sont intégrées dans la structure utilisateur pour plus de lisibilité et d'abstraction. Cela vous permettrait d'écrire user.Save() au lieu de data.Save(user).

Exemple

Considérez cet extrait de code :

package main

import (
    "fmt"
    "reflect"
)

func main() {
    test := Foo{Bar: &Bar{}, Name: "name"}
    test.Test()
}

type Foo struct {
    *Bar
    Name string
}

func (s *Foo) Method() {
    fmt.Println("Foo.Method()")
}

type Bar struct {
}

func (s *Bar) Test() {
    t := reflect.TypeOf(s)
    v := reflect.ValueOf(s)
    fmt.Printf("model: %+v %+v %+v\n", s, t, v)
    fmt.Println(s.Name)
    s.Method()
}

Question revisitée

La question qui se pose est de savoir s'il y a un moyen de rendre les champs de niveau supérieur accessibles à partir de méthodes intégrées. Dans l'exemple ci-dessus, la méthode Test est intégrée dans Bar et tente d'accéder au champ Nom à partir de la structure Foo parent.

Réponse

Malheureusement, Go ne fournit pas tout mécanisme direct permettant aux méthodes intégrées d'accéder aux champs de leur structure parent. Le récepteur de la méthode Test est un pointeur vers Bar, et Go n'a aucun moyen de déterminer s'il est intégré ou non.

Solution possible

Pour y parvenir Pour cette fonctionnalité, une solution de contournement potentielle consiste à ajouter un membre interface{} à la structure Bar, exigeant que les types qui l'implémentent définissent le membre sur le type conteneur. L'initialisation de ce membre peut être soit de la responsabilité de l'appelant, soit gérée via une méthode ORM. Cependant, cette approche introduit une complexité supplémentaire et des problèmes de maintenance potentiels.

Perspective alternative

Vous pouvez également envisager la possibilité que la structuration de l'API en tant que db.Save(user) ne puisse pas être aussi préjudiciable qu'il y paraît. Cette approche offre un moyen simple de prendre en charge plusieurs bases de données et évite de dépendre de l'état global.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!