Go-Interfaces: implizite Erfüllung und das nicht-nil nil

Worum es geht

Die Spezifikation definiert einen Interface-Typ als eine Typmenge; eine Variable vom Interface-Typ kann einen Wert jedes Typs dieser Menge speichern, und ein solcher Typ implementiert das Interface. Die Implementierung ist strukturell: *os.File implementiert io.Reader, weil es Read([]byte) (int, error) besitzt, nicht weil es das behauptet. Seit Go 1.18 dienen Interfaces auch als Typ-Constraints für Generics, wo sie Typen auflisten und comparable einbetten können. Type Assertions (v, ok := x.(T)) und Type Switches ermitteln den konkreten Typ zur Laufzeit. Das Go-FAQ erklärt die Repräsentation: Ein Interface-Wert enthält einen Typ und einen Wert, und er ist nur dann nil, wenn beide nicht gesetzt sind.

Warum es wichtig ist

Wer an Duck Typing gewöhnt ist, findet das vertraut, mit einem Unterschied: Der Compiler prüft die «Ente». Pythons Protocol und die strukturellen Typen von TypeScript sind die nächsten Verwandten. Die Repräsentation hat eine Konsequenz, die Python nicht kennt: Ein *MyError-Pointer, der nil ist und als error zurückgegeben wird, ergibt ein Interface mit Typ *MyError und Wert nil, das ungleich nil verglichen wird. Das FAQ zeigt genau eine solche Funktion und weist darauf hin, dass sie stets einen nicht-nil-Fehler zurückgibt.

So wird es angewendet

• Interfaces dort definieren, wo sie konsumiert werden, mit so wenigen Methoden, wie der Konsument braucht; die einmethodigen io.Reader, io.Writer und fmt.Stringer der Standardbibliothek sind das Vorbild, und der Abschnitt zu Interfaces in Effective Go argumentiert ebenso.
• Interfaces als Parameter entgegennehmen und konkrete Typen aus Konstruktoren zurückgeben; Aufrufende können dann eine Abhängigkeit in Tests einpacken oder simulieren, ohne ein Mocking-Framework.
• Die Erfüllung zur Kompilierzeit mit var _ io.Writer = (*Buffer)(nil) absichern, wenn ein Typ etwas implementieren soll.
• Auf Method Sets achten: Eine Methode mit Pointer-Receiver gehört zu *T, nicht zu T, sodass ein einfacher Wert von T das Interface nicht erfüllt; der Compiler meldet das.
• Von einer Funktion, deren Ergebnistyp error ist, buchstäblich nil zurückgeben, nie einen typisierten nil-Pointer.

Stolpersteine

Grosse Interfaces zwingen jede Fake-Implementierung, alles zu implementieren. Interfaces, die nur existieren, um Mocking zu ermöglichen, mit einer einzigen Implementierung, fügen Indirektion hinzu, ohne einen zweiten Konsumenten. any-Parameter verschieben Typfehler von der Kompilierzeit zur Laufzeit; Generics mit einem Constraint sind meist das bessere Werkzeug. Der Vergleich zweier Interface-Werte, deren identischer dynamischer Typ nicht vergleichbar ist (ein Slice, eine Map oder eine Funktion), löst zur Laufzeit eine Panic aus, ebenso die Verwendung eines solchen Werts als Map-Schlüssel.