Maison >développement back-end >Golang >Devriez-vous utiliser des structures intégrées pour définir des données dans les interfaces Go ?
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.
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.
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) }
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!