Interfaces: behaviour, not family trees

The problem interfaces solve

Imagine a checkout that can charge by UPI, card or wallet. Without interfaces you would write a separate checkout for each, or a big switch. An interface lets you say: "I accept anything that can Pay(amount)". Each payment type implements Pay in its own way, and the checkout code never changes when you add a new one.

type PaymentMethod interface {
	Pay(paise int64) error
}

type UPI struct{ VPA string }
type Card struct{ Last4 string }

func (u UPI) Pay(p int64) error {
	fmt.Println("UPI", u.VPA, "paid", p)
	return nil
}

func (c Card) Pay(p int64) error {
	fmt.Println("Card", c.Last4, "paid", p)
	return nil
}

func checkout(m PaymentMethod, total int64) error {
	return m.Pay(total)
}

func main() {
	checkout(UPI{VPA: "asha@okbank"}, 49900)
	checkout(Card{Last4: "4242"}, 120000)
}

Implicit satisfaction

In Java you write class UPI implements PaymentMethod. Go has no such keyword. A type satisfies an interface just by having all its methods with the exact signatures. This means you can define an interface later, in the package that USES it, for types you did not write.

Small interfaces from the standard library

Because io.Writer is tiny, one function like fmt.Fprintf(w io.Writer, ...) can write to the screen, a file, an HTTP response or a buffer in memory. That is the power of small interfaces: "the bigger the interface, the weaker the abstraction" is a well-known Go proverb.

type Rupees int64

func (r Rupees) String() string {
	return fmt.Sprintf("Rs %d.%02d", r/100, r%100)
}

func main() {
	var price Rupees = 49950
	fmt.Println(price) // Rs 499.50
}

Pointer receivers and interfaces

If a method has a pointer receiver, only the pointer type has that method in its method set. So *T satisfies the interface but T does not. The compiler tells you clearly.

type Counter struct{ n int }
func (c *Counter) Inc() { c.n++ }

type Incrementer interface{ Inc() }

var _ Incrementer = &Counter{}  // OK
// var _ Incrementer = Counter{} // compile error: Counter does not implement
//                               // Incrementer (method Inc has pointer receiver)

Interfaces make testing easy

If your code depends on an interface instead of a concrete database or payment gateway, a test can pass in a fake that records calls. No real money moves and no network is needed. This is why Go developers say: accept interfaces, return concrete types (structs).

type fakePay struct{ calls int }

func (f *fakePay) Pay(p int64) error { f.calls++; return nil }

// in a test:
// f := &fakePay{}
// checkout(f, 100)
// if f.calls != 1 { t.Fatal("expected one payment") }

Design tips and mistakes

• Keep interfaces small: one to three methods is normal.
• Define the interface where it is used (the consumer), not next to the type that implements it.
• Do not create an interface for every struct "just in case". Add one when you have two implementations, or need a fake for tests.
• Interface names for single methods often end in -er: Reader, Writer, Stringer, Notifier.