Jak działają interfejsy w Go?

Question

Accepted Answer

**Interfejs** w Go definiuje zestaw sygnatur metod — umowę na temat zachowania. Kluczową cechą jest to, że interfejsy są spełniane **niejawnie**: każdy typ posiadający te metody automatycznie spełnia interfejs, **bez jawnej deklaracji "implements"**. To strukturalne, oparte na duck-typingu podejście jest charakterystyczne i potężne.

## Definiowanie i niejawna implementacja interfejsu

```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"
```

Nie ma słowa kluczowego `implements` — jeśli typ ma wszystkie metody interfejsu, spełnia go automatycznie. To rozprzęga interfejs od jego implementacji (implementujący nie musi nawet wiedzieć, że interfejs istnieje).

## Polimorfizm poprzez interfejsy

```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() }
```

Interfejsy umożliwiają polimorfizm — pisz kod względem zachowania, a każdy zgodny typ będzie działać.

## Pusty interfejs i `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
```

Pusty interfejs (`interface{}` / `any`) może przechowywać dowolną wartość — używany, gdy typ nie jest znany z góry (choć generyki często go zastępują).

## Interfejsy biblioteki standardowej, które będziesz używać nieustannie

```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) }
```

Wielka część biblioteki standardowej zbudowana jest na małych interfejsach (`io.Reader`/`io.Writer`, `error`, `Stringer`) — ich implementacja sprawia, że Twoje typy współpracują z całym ekosystemem.

## Idiom: akceptuj interfejsy, zwracaj struktury

```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."
```

## Dlaczego to ważne

Interfejsy są centralne dla projektu Go i jego podejścia do abstrakcji i polimorfizmu — a ich **niejawne spełnianie** (brak słowa kluczowego `implements`; typowanie strukturalne) to jedna z najbardziej charakterystycznych i potężnych cech języka.

To rozprzęgniecie oznacza, że typy i interfejsy ewoluują niezależnie, możesz definiować interfejsy *po* typach, które je spełniają, a każdy zgodny typ automatycznie wpisuje się w kod oparty na interfejsach — umożliwiając elastyczne, luźno sprzężone projekty i łatwe testowanie (wstawiaj makietowe implementacje).

Zrozumienie niejawnej implementacji, polimorfizmu poprzez interfejsy, pustego interfejsu/`any`, idiomatu małych interfejsów ("akceptuj interfejsy, zwracaj struktury") i wszechobecnych interfejsów biblioteki standardowej (`error`, `io.Reader`/`Writer`, `Stringer`) jest niezbędne do idiomatycznego Go.

To częsty temat rozmów o pracę właśnie dlatego, że niejawny model strukturalny różni się tak fundamentalnie od jawnych interfejsów w Javie/C#.

Definiowanie i niejawna implementacja interfejsu

Polimorfizm poprzez interfejsy

Pusty interfejs i any

Interfejsy biblioteki standardowej, które będziesz używać nieustannie

Idiom: akceptuj interfejsy, zwracaj struktury

Dlaczego to ważne

Pusty interfejs i `any`