Wie funktionieren Interfaces in Go?

Question

Accepted Answer

Ein Go **Interface** definiert eine Menge von Methodensignaturen — einen Verhaltensvertrag. Entscheidend ist, dass Interfaces **implizit** erfüllt werden: Jeder Typ, der diese Methoden hat, erfüllt das Interface automatisch, **ohne explizite "implements"-Deklaration**. Dieser strukturelle, Duck-Typing-Ansatz ist charakteristisch und mächtig.

## Defining and implicitly implementing an interface

```go
// define an interface — a set of method signatures
type Speaker interface {
    Speak() string
}

type Dog struct{}
func (d Dog) Speak() string { return "Woof" }   // Dog has Speak() → it IS a Speaker

type Cat struct{}
func (c Cat) Speak() string { return "Meow" }   // Cat too — implicitly

// NO "implements Speaker" anywhere — satisfaction is automatic
var s Speaker = Dog{}    // works because Dog has the Speak() method
s.Speak()                // "Woof"
```

Es gibt kein `implements`-Schlüsselwort — wenn ein Typ alle Methoden des Interfaces hat, erfüllt er das Interface automatisch. Dies entkoppelt das Interface von seinen Implementierungen (der Implementierer muss nicht einmal wissen, dass das Interface existiert).

## Polymorphismus durch Interfaces

```go
func announce(s Speaker) {        // accepts ANY type that has Speak()
    fmt.Println(s.Speak())
}
announce(Dog{})    // "Woof"
announce(Cat{})    // "Meow"

speakers := []Speaker{Dog{}, Cat{}}   // a slice of different types via the interface
for _, sp := range speakers { sp.Speak() }
```

Interfaces ermöglichen Polymorphismus — schreibe Code gegen das Verhalten, und jeder konforme Typ funktioniert.

## Das leere Interface und `any`

```go
var x interface{}     // the empty interface — satisfied by EVERY type (no methods required)
x = 42
x = "hello"
// Go 1.18+: `any` is an alias for interface{}
func print(v any) { fmt.Println(v) }   // accepts anything
```

Das leere Interface (`interface{}` / `any`) hält jeden Wert — wird verwendet, wenn der Typ vorher nicht bekannt ist (obwohl Generics dies jetzt oft ersetzen).

## Standard-Library-Interfaces, die du ständig verwendest

```go
type Stringer interface { String() string }   // controls fmt printing
type error interface { Error() string }        // the error type itself!
type io.Reader interface { Read(p []byte) (n int, err error) }
type io.Writer interface { Write(p []byte) (n int, err error) }
```

Viel der Standard Library ist auf kleine Interfaces (`io.Reader`/`io.Writer`, `error`, `Stringer`) gebaut — ihre Implementierung macht deine Typen mit dem ganzen Ökosystem kompatibel.

## Das Idiom: Akzeptiere Interfaces, gib Structs zurück

```text
Go favors SMALL interfaces (often one method) defined where they're USED (the consumer),
not where types are defined. "The bigger the interface, the weaker the abstraction."
```

## Warum es wichtig ist

Interfaces sind zentral für Gos Design und seinen Ansatz zur Abstraktion und zum Polymorphismus — und ihre **implizite Erfüllung** (kein `implements`-Schlüsselwort; strukturelles Typing) ist eines der charakteristischsten und mächtigsten Features der Sprache.

Diese Entkopplung bedeutet, dass Typen und Interfaces unabhängig voneinander evolvieren, du Interfaces *nach* den Typen definieren kannst, die sie erfüllen, und jeder konforme Typ sich automatisch in Interface-basierten Code einfügt — dies ermöglicht flexible, lose gekoppelte Designs und einfaches Testen (swap in Mock-Implementierungen).

Das Verständnis von impliziter Implementierung, Polymorphismus über Interfaces, dem leeren Interface/`any`, dem Small-Interface-Idiom ("akzeptiere Interfaces, gib Structs zurück") und den allgegenwärtigen Standard-Library-Interfaces (`error`, `io.Reader`/`Writer`, `Stringer`) ist unverzichtbar für idiomatisches Go.

Es ist ein häufiges Interview-Thema, genau weil das implizite, strukturelle Modell sich grundlegend von den expliziten Interfaces von Java/C# unterscheidet.

Defining and implicitly implementing an interface

Polymorphismus durch Interfaces

Das leere Interface und any

Standard-Library-Interfaces, die du ständig verwendest

Das Idiom: Akzeptiere Interfaces, gib Structs zurück

Warum es wichtig ist

Das leere Interface und `any`