Maison >développement back-end >Golang >Devriez-vous utiliser des structures intégrées pour définir des données dans les interfaces Go ?

Devriez-vous utiliser des structures intégrées pour définir des données dans les interfaces Go ?

Barbara Streisand
Barbara Streisandoriginal
2024-12-15 13:34:10870parcourir

Should You Use Embedded Structs to Define Data in Go Interfaces?

Champs de l'interface Go : utiliser ou ne pas utiliser ?

Dans Go, les interfaces sont généralement utilisées pour définir des fonctionnalités plutôt que des données. Cela signifie que même si vous pouvez spécifier des méthodes dans une interface, vous ne pouvez spécifier aucun champ obligatoire dans les implémentations.

Cependant, en utilisant des structures intégrées, il est possible de créer des interfaces qui définissent efficacement les données en les exposant via des méthodes.

Exemple :

Considérons l'exemple suivant :

type PersonProvider interface {
    GetPerson() *Person
}

type Person struct {
    Name string
    Age  int64
}

func (p *Person) GetPerson() *Person {
    return p
}

type Bob struct {
    FavoriteNumber int64
    Person
}

Dans cet exemple, le L'interface PersonProvider définit une méthode qui renvoie un pointeur vers un objet Person. La structure Personne contient les champs de données Nom et Âge. La structure Bob intègre la structure Person, héritant efficacement de ses champs.

Fonctions interagissant avec les données :

Les fonctions peuvent interagir avec les données intégrées via la méthode GetPerson() :

func SayHi(pp PersonProvider) {
    fmt.Printf("Hello, %v!\r", pp.GetPerson().Name)
}

func main() {
    b := &Bob{
        5,
        Person{"Bob", 23},
    }
    SayHi(b)
    fmt.Printf("You're %v years old now!", b.Age)
}

Discussion :

Cette technique permet des interfaces qui définissent les données plutôt que le comportement. Il offre une flexibilité accrue en permettant aux structures d'implémenter des interfaces sans exposer leurs champs concrets. Cependant, il est important de noter que l'exposition des pointeurs accorde toujours un accès direct aux données, offrant une flexibilité supplémentaire limitée.

De plus, les conventions Go ne nécessitent pas toujours l'utilisation d'abstractions pour l'accès aux données. Dans de nombreux cas, l’exposition des attributs de données via l’intégration ou des champs publics est acceptable. Lorsque vous envisagez cette technique, il est recommandé d’évaluer au cas par cas si elle offre des avantages significatifs par rapport à l’exposition directe des attributs. Si l'exposition des données via des getters et des setters n'est pas cruciale pour la flexibilité future ou la compatibilité des API, les attributs publics peuvent être une solution plus simple.

Dans l'ensemble, même si la technique présentée est une astuce intelligente, il est conseillé d'en évaluer la nécessité. attentivement et envisager des approches alternatives qui pourraient être plus appropriées dans certains contextes.

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn