Interfaces: depend on a behavior, not on a type

A method (Lesson 04) attaches behavior to one concrete type. But the whole point of programming in the large is that code on one team should not know — or care — which concrete type another team will hand it. The interface is Go's answer, and it is a deeply un-Go-looking idea executed in the most Go way possible: a type satisfies an interface by having the methods, with no declaration, no implements, no shared base class. This lesson explains why that "structural" choice is the bargain in its purest form, what an interface value actually is at runtime, the one nil trap it creates, and the two design rules — small interfaces, "accept interfaces, return structs" — that turn the feature into team-scale leverage.

1 · The problem: code welded to a concrete type

Say you write a function that logs an event somewhere. Today "somewhere" is a file. So you write it against *os.File:

func Log(f *os.File, msg string) {
    f.WriteString(time.Now().Format(time.RFC3339) + " " + msg + "\n")
}

This works exactly once, then becomes a liability. Tomorrow someone wants to log to a network socket; next week to an in-memory buffer in a test; next month to a gzip stream. Each is a different concrete type, and Log has welded itself to *os.File. The function never actually needed a file — it needed something it could write bytes to. It depended on a concretion when all it used was a behavior. That is the maintenance bill question 4 is built to catch.

The object-oriented tradition has a fix, and it is instructive to see why Go rejected it. You declare an abstract base — abstract class Writer or interface Writer with an explicit implements — and every writable thing must declare that it extends or implements it. That decouples Log from *os.File, but it introduces a new coupling: every concrete type is now bound to the hierarchy, the hierarchy must be designed before any consumer can use it, and a type you don't own (one from a third-party package, or the standard library, written before your interface existed) cannot participate because it never declared the membership. The decoupling at the call site was bought with coupling everywhere else. Under the Go bargain, that is complexity that was not earned.

2 · Go's answer: satisfaction by structure, not declaration

An interface in Go is a named set of method signatures — a behavior contract — and nothing more:

type Writer interface {
    Write(p []byte) (n int, err error)
}

The pivotal decision: a type satisfies Writer if and only if its method set includes Write(p []byte) (int, error). There is no implements keyword, no declaration, no link from the type back to the interface. The compiler checks the methods are present; satisfaction is structural. *os.File, *bytes.Buffer, net.Conn, a gzip.Writer — none of them mention this interface, and all of them satisfy it, because they all happen to have a matching Write method. (This exact interface is io.Writer in the standard library; Lesson 13 is built around it.) Rewrite Log to ask for the behavior:

func Log(w io.Writer, msg string) (int, error) {
    return io.WriteString(w, time.Now().Format(time.RFC3339)+" "+msg+"\n")
}

Now Log works on a file, a socket, a buffer, a gzip stream, an HTTP response, and a thing your colleague will write next year — none of which had to know Log exists. The decoupling is total and cost the implementing types nothing.

One guardrail you'll want: because nothing links a type to the interfaces it satisfies, it is easy to think a type implements an interface and be silently wrong. The idiom is a compile-time assertion — a throwaway assignment to the blank identifier that fails to compile if the contract is broken:

var _ io.Writer = (*MyType)(nil)  // compile error if *MyType lacks Write

3 · What an interface value actually is

An interface variable is not the concrete value, and it is not a pointer to it in the usual sense. At runtime an interface value is a two-word pair (16 bytes on a 64-bit machine): a pointer to a type descriptor (which concrete type is in here, including its method table) and a pointer to the data (the concrete value, on the heap if it doesn't fit in a word). Internally this is the itab (interface table — type info + the resolved method pointers) and the data word.

Two consequences fall straight out of this layout. First, a method call through an interface costs an indirection. w.Write(b) reads the method pointer out of the type descriptor's table and calls it — it cannot be inlined the way a direct call on a concrete type can. The cost is a few nanoseconds, not free; in a hot inner loop called millions of times this is measurable, which is the honest reason you don't reach for an interface where a concrete type does the job. Second, putting a value into an interface may copy it to the heap. Assigning a large struct value (not a pointer) to an interface boxes a copy; this is one of the cases the escape analysis from Lesson 03 resolves as "escapes to heap." Passing a pointer into the interface avoids the copy and is the common case.

func do() error {
    var p *MyError = nil   // a typed nil pointer
    if somethingFailed {
        p = &MyError{...}
    }
    return p               // BUG: returns a NON-nil error wrapping a nil *MyError
}

if err := do(); err != nil {   // TRUE even on success — type word is *MyError
    // ...wrongly taken
}

func do() error {
    if somethingFailed {
        return &MyError{...}
    }
    return nil   // a true nil interface: both words nil
}

4 · The two design rules that make interfaces pay

The feature is only leverage if you use it the Go way. Two rules carry almost all of the value.

4.1 · Small interfaces — "the bigger the interface, the weaker the abstraction"

A large interface (ten methods) is barely more abstract than a concrete type: almost nothing can satisfy it except the one struct it was carved from, and every consumer is coupled to all ten methods even if it calls one. A small interface — one or two methods — is satisfied by a huge population of types and demands almost nothing of its consumers. The standard library's most reused abstractions are one method each:

Because io.Copy(dst Writer, src Reader) depends only on those two one-method behaviors, it copies between any reader and any writer — a file to a socket, a buffer to a gzip stream — without ever naming a concrete type. That single function is the dividend of small interfaces, and it is why Lesson 13 calls the standard library a teacher of taste.

4.2 · Accept interfaces, return structs

The second rule is about where an interface should appear in a signature. Take interfaces as parameters; return concrete types. Accepting an interface maximizes who can call you — the input rule from §1. Returning a concrete type maximizes what the caller can do with the result: they get the full type with all its methods and fields, and they decide which narrow interface to view it through, rather than you pre-deciding and throwing capability away.

// Good: callable by anything readable; returns a concrete, fully-featured type.
func NewScanner(r io.Reader) *Scanner { ... }

// Usually worse: forces every caller into your narrow view of the result,
// and hides the concrete type's other useful methods.
func NewScanner(r io.Reader) ReaderCloser { ... }

The companion rule — define the interface where it is consumed, not where the type is defined — completes the picture. The package that uses a behavior declares the small interface it needs; the package that provides the concrete type ships the struct and stays ignorant of every interface that will ever view it. This is the structural-satisfaction payoff made into a layout convention: dependencies point inward, toward the consumer's small contract, and no provider is ever coupled to a consumer it has never heard of.

Checkpoint exercise

Where this points next

Interfaces give you polymorphism — abstraction across types by behavior. The missing half is how you build bigger types out of smaller ones without the inheritance Go refused. Lesson 06 supplies it: embedding, where a struct includes another type and promotes its fields and methods so the outer type satisfies interfaces through its parts. It also closes the loop on this lesson — the empty interface any (an interface with zero methods, satisfied by everything), and how you safely pull the concrete type back out of an interface value with type assertions and type switches, reaching directly into the (type, data) pair you just learned about. Composition is what you do instead of a class hierarchy; interfaces are how the result stays usable.

Interview prompts

• How does a Go type declare that it implements an interface? (§2 — it doesn't: satisfaction is structural and implicit, checked by the compiler at the use site from the method set; there is no implements keyword, which lets types you don't own satisfy interfaces they predate.)
• What is an interface value at runtime, and how big is it? (§3 — a two-word pair, 16 bytes on 64-bit: a pointer to a type descriptor / method table (itab) and a pointer to the concrete data; nil only when both words are nil.)
• Why can a function return a non-nil error even when "nothing went wrong"? (§3 — the typed-nil trap: storing a typed nil pointer (*MyError) in the interface sets the type word, so the interface is non-nil though its data is nil; fix by returning literal nil, never a typed nil.)
• What does a method call through an interface cost versus a direct call? (§3 — an indirection: the method pointer is read from the type descriptor's table and called, so it can't be inlined — a few ns, measurable only in hot loops; and boxing a large value into an interface copies it to the heap.)
• Why is a small interface a stronger abstraction than a large one? (§4.1 — "the bigger the interface, the weaker the abstraction": one- or two-method interfaces are satisfied by a huge population of types and couple consumers to almost nothing, which is why io.Reader/Writer let io.Copy work on anything.)
• Explain "accept interfaces, return structs" and where to define the interface. (§4.2 — accept interfaces to maximize who can call you; return concrete types so callers keep full capability and choose their own narrow view; define the interface in the consuming package so dependencies point inward and providers stay decoupled.)
• How does the interface relate to method sets from Lesson 04? (§2–3 — satisfaction is checked against the method set, so a value-receiver method puts the method in both the value's and the pointer's set, while a pointer-receiver method is only in the pointer's set — meaning a value may fail to satisfy an interface its pointer satisfies.)