© StonePictures/Shutterstock.com
Im Schnitt, ja

Die Golumne


Schnittstellen als Sprachmittel haben sich von Beginn an in Go etabliert und bewährt. Sie abstrahieren Erwartungshaltungen an Typen. Mit einem definierten Interface kann ich festlegen, zu was ein Argument einer meiner Funktionen beziehungsweise Methoden fähig sein soll. Oder im Gegenteil die Rückgabe einer Funktion. Sie kann auf einem Interface basieren, auf das sich der nutzende Code verlassen kann. Die Implementierung basiert dabei auf Argumenten der Funktion. Letzteres habe ich auf meinem Berufsweg mehrfach bei der Kapselung von Cloud-APIs kennenlernen dürfen.

Schön ist, dass ein Typ hierbei nicht definieren muss, welche Interfaces er implementiert. Ich definiere es zwar in meinem nutzenden Package, aus Sicht des Implementors muss diese Schnittstelle aber nicht referenziert werden. Ein Beispiel in Listing 1 ist hier ein Dumper für die Ausgabe von Instanzen als Byte Slices. Dieses Interface wird von der Funktion WriteDump() erwartet. Sie schreibt die Daten in eine Datei mit dem angegebenen Namen.

Listing 1: Definition und Nutzung des Dumpers

package writer import ( "io/ioutil" "os" ) type Dumper interface { Dump() ([]byte, error) } func WriteDump( filename string, dumper Dumper, perm os.FileMode, ) error { dump, err := dumper.Dump() if err != nil { return err } return ioutil.WriteFile(filename, dump, perm) }

Dieses Interface vor Augen habe ich zum Beispiel bei meiner Implementierung des Typs User. Diesen möchte ich im JSON-Format in Dateien speichern können, weshalb ich den Benutzer zusätzlich mit der Dump()-Methode ausstatte (Listing 2). Wie gesagt teile ich dem Compiler nicht mit, dass der User das Interface umsetzt. Ohne eine Methode dieser Signatur würde ein Versuch von WriteDump() einen klaren Compilerfehler mit Hinweis auf ein nicht implementiertes Interface ausgeben.

Listing 2: Implementierung des Dumpers

type User struct { ... } // Weitere Methoden func (u User) Dump() ([]byte, error) { return json.Marshal(u)}

Übergreifend

Dennoch gibt es diverse Interfaces, die in zentralen Packages definiert werden. Dies geschieht weniger mit einer konkreten nutzenden oder erzeugenden Funktion im Blick. Sie sollen vielmehr eine Strategie, ein Design definieren. Die Freiheit der Interfaces ist angenehm, an einer größeren Bibliothek schätzen wir jedoch hingegen, dass sich bekannte Muster übergreifend wiederfinden. Sie erleichtern die Anwendung und die Komposition von Typen.

Ein wichtiger Vertreter ist das Package io. Hier ist die Anzahl von Interfaces im Gegen...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang