Chapter 1: Interfaces & Type System

Go’s interface system is one of its most powerful features. Unlike many languages, Go interfaces are implicitly satisfied - there’s no implements keyword. A type satisfies an interface simply by implementing all of its methods.

This implicit satisfaction is a fundamental design choice. In languages like Java, you must explicitly declare that a class implements an interface. In Go, if your type has the right methods, it satisfies the interface automatically. This enables loose coupling and makes it easy to adapt existing types to new interfaces.

Interfaces are Go’s only abstraction mechanism. No classes, no inheritance, no generics (until Go 1.18). Just interfaces and composition. This simplicity forces clear thinking about abstractions and leads to flexible, maintainable code.

Interface Basics

Understanding Implicit Satisfaction

An interface defines a set of method signatures. Any type that implements those methods automatically satisfies the interface. You never declare intent to implement an interface - if the methods match, the type satisfies it.

This decoupling is powerful. A library can define an interface, and your existing types can satisfy it without modification. You can define interfaces for types you don’t own. Standard library interfaces like io.Reader work with countless third-party types, all without explicit coupling.

Copy

▶Open Editor

Interface Composition

Interfaces can embed other interfaces, creating more specific contracts. This is a powerful way to build up complex behaviors from simple parts.

Copy

▶Open Editor

The Empty Interface

The empty interface has no methods, so every type satisfies it. Since Go 1.18 it is spelled any, which is a predeclared alias for interface{}. The two are identical to the compiler, but any is the idiomatic spelling in new code - you will only see interface{} in code written before 1.18. Use the empty interface sparingly either way: it trades compile-time safety for flexibility.

Copy

▶Open Editor

Type Assertions

When you have an interface value, you often need to access the underlying concrete type. Type assertions let you do this safely.

Copy

▶Open Editor

Common Gotcha

Always use the two-value form v, ok := i.(Type) unless you’re absolutely certain of the type. The single-value form v := i.(Type) will panic if the assertion fails.

Type Switches

Type switches are a cleaner way to handle multiple possible types:

Copy

▶Open Editor

Interface Satisfaction

A type satisfies an interface if it implements all required methods with matching signatures. The compiler checks this automatically.

Copy

▶Open Editor

Best Practice

Add a compile-time interface check with var _ Interface = Type{} to catch missing methods early.

Pointer vs Value Receivers

Methods can have pointer or value receivers. This affects interface satisfaction:

Copy

▶Open Editor

Remember

• A pointer type *T can use both pointer and value receiver methods
• A value type T can only use value receiver methods for interface satisfaction
• Don’t mix receiver kinds on one type. If any method needs a pointer receiver, give every method a pointer receiver. A type with mixed receivers has two different method sets, so T and *T satisfy different interfaces - and a value copy silently loses mutations

Method set surprise

The compiler’s automatic &/* insertion only applies to addressable values. MyCounter{}.Increment() and m[key].Increment() (map elements) do not compile, and neither does assigning a MyCounter value to a Counter variable. Consistent pointer receivers plus a compile-time check (var _ Counter = (*MyCounter)(nil)) make these mistakes show up at build time.

Key Takeaways

1. Implicit satisfaction - Types implement interfaces automatically by having the right methods
2. Composition over inheritance - Embed interfaces to build up behaviors
3. Empty interface sparingly - any sacrifices type safety; prefer specific interfaces
4. Type assertions safely - Always use the two-value form v, ok := i.(T)
5. Type switches - Cleaner than chains of type assertions
6. Pointer receivers matter - *T and T have different interface satisfaction rules

---

Exercise

Shape Calculator

medium

Create a Shape interface with Area() and Perimeter() methods. Implement it for Rectangle and Circle types. Then write a function that takes a Shape and prints both its area and perimeter.

Copy

▶Open Editor

Show Hint

---

Practice

Interfaces are the seam that makes Go code testable: you depend on a small interface, and swap in a fake when you test. Work through the testing battery to see that play out:

• Testing Exercises - especially 2. Mocking with Interfaces, which is this chapter applied directly
• Generics Exercises - the modern alternative to any when you want type safety back

---

○Chapter in progress

0 / 14 chapters completed

Mark Chapter as Complete

Next up: Chapter 2: Error Handling Patterns