Les interfaces Go : satisfaction implicite et le nil qui n'en est pas un

Ce que c'est

La spécification définit un type interface comme un ensemble de types ; une variable de type interface peut stocker une valeur de n'importe quel type de cet ensemble, et un tel type est dit implémenter l'interface. L'implémentation est structurelle : *os.File implémente io.Reader parce qu'il possède Read([]byte) (int, error), pas parce qu'il le déclare. Depuis Go 1.18, les interfaces servent aussi de contraintes de type pour les génériques, où elles peuvent lister des types et embarquer comparable. Les assertions de type (v, ok := x.(T)) et les type switches récupèrent le type concret à l'exécution. La FAQ Go explique la représentation : une valeur d'interface contient un type et une valeur, et elle vaut nil seulement quand les deux sont vides.

Pourquoi c'est important

Pour quiconque est habitué au duck typing, cela paraît familier, à une différence près : le compilateur vérifie le canard. Le Protocol de Python et les types structurels de TypeScript en sont les plus proches parents. La représentation a une conséquence que Python n'a pas : un pointeur *MyError valant nil, retourné en tant qu'error, produit une interface de type *MyError et de valeur nil, qui n'est pas égale à nil lors de la comparaison. La FAQ montre exactement une telle fonction et note qu'elle retournera toujours une erreur non nil.

Comment l'appliquer

• Définir les interfaces là où elles sont consommées, avec le moins de méthodes possible pour le consommateur ; les interfaces à une seule méthode de la bibliothèque standard, io.Reader, io.Writer et fmt.Stringer, en sont le modèle, et la section d'Effective Go sur les interfaces va dans le même sens.
• Accepter des interfaces en paramètres et retourner des types concrets depuis les constructeurs ; les appelants peuvent alors envelopper ou simuler une dépendance dans les tests sans framework de mock.
• Vérifier la satisfaction à la compilation avec var _ io.Writer = (*Buffer)(nil) lorsqu'un type est censé implémenter quelque chose.
• Faire attention aux ensembles de méthodes : une méthode à récepteur pointeur appartient à *T, pas à T, si bien qu'une simple valeur de T ne satisfait pas l'interface ; le compilateur le signale.
• Retourner nil littéralement, jamais un pointeur nil typé, depuis une fonction dont le type de résultat est error.

Pièges

Les grandes interfaces forcent chaque simulation à tout implémenter. Les interfaces qui n'existent que pour permettre le mock, avec une seule implémentation, ajoutent de l'indirection sans second consommateur. Les paramètres any repoussent les erreurs de type de la compilation à l'exécution ; les génériques avec une contrainte sont généralement le meilleur outil. Comparer deux valeurs d'interface dont le type dynamique identique n'est pas comparable (un slice, une map ou une fonction) panique à l'exécution, tout comme utiliser une telle valeur comme clé de map.