How do interfaces work in Go?

Question

Accepted Answer

A Go **interface** defines a set of method signatures — a contract of behavior. Crucially, interfaces are satisfied **implicitly**: any type that has those methods automatically satisfies the interface, with **no explicit "implements" declaration**. This structural, duck-typing approach is distinctive and powerful.

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

There's no `implements` keyword — if a type has all the interface's methods, it satisfies the interface automatically. This decouples the interface from its implementations (the implementer doesn't even need to know the interface exists).

## Polymorphism through 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 enable polymorphism — write code against the behavior, and any conforming type works.

## The empty interface and `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
```

The empty interface (`interface{}` / `any`) holds any value — used when the type isn't known ahead of time (though generics now often replace this).

## Standard library interfaces you'll use constantly

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

Much of the standard library is built on small interfaces (`io.Reader`/`io.Writer`, `error`, `Stringer`) — implementing them makes your types work with the whole ecosystem.

## The idiom: accept interfaces, return structs

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

## Why it matters

Interfaces are central to Go's design and its approach to abstraction and polymorphism — and their **implicit satisfaction** (no `implements` keyword; structural typing) is one of the most distinctive and powerful features in the language.

This decoupling means types and interfaces evolve independently, you can define interfaces *after* the types that satisfy them, and any conforming type plugs into interface-based code automatically — enabling flexible, loosely-coupled designs and easy testing (swap in mock implementations).

Understanding implicit implementation, polymorphism via interfaces, the empty interface/`any`, the small-interface idiom ("accept interfaces, return structs"), and the ubiquitous standard-library interfaces (`error`, `io.Reader`/`Writer`, `Stringer`) is essential to idiomatic Go.

It's a frequent interview topic precisely because the implicit, structural model differs so fundamentally from the explicit interfaces of Java/C#.

Defining and implicitly implementing an interface

Polymorphism through interfaces

The empty interface and any

Standard library interfaces you'll use constantly

The idiom: accept interfaces, return structs

Why it matters

The empty interface and `any`