Think about a job posting for a "Senior Executive Assistant." The job description doesn't usually list every single single human skill from scratch. Instead, it might say, "Must be an expert Calendar Manager AND an expert Travel Coordinator." The role of the Assistant is essentially a composition of two other, smaller roles. If you can handle the calendar and you can handle the travel, you satisfy the requirements for the Assistant role.

In Go, interface composition works exactly like that. Instead of defining a massive interface with fifteen methods, you define small, focused interfaces and then embed them into a larger one. You're essentially saying, "To satisfy this new interface, you must satisfy all of these other interfaces first."

Combining Capabilities

Let's look at a real-world scenario: a file system. You might have some objects that can only be read from, and some that can only be written to. Rather than creating one giant File interface and forcing every single object to implement every method, we break them apart.

type Reader interface {
    Read(p []byte) (n int, err error)
}

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

// ReadWriter is a composed interface. 
// It embeds both Reader and Writer.
type ReadWriter interface {
    Reader
    Writer
}

Notice that ReadWriter doesn't have any methods of its own. It just "borrows" the requirements from the other two. If I write a function that takes a ReadWriter, I can be 100% certain that whatever object I'm handed has both a Read and a Write method. It's a clean way to build complex requirements out of simple building blocks.

Why bother with this instead of one big interface?

I've seen a lot of developers start by creating "God Interfaces"—interfaces with twenty methods that try to cover every single possibility. The problem is that your code becomes incredibly rigid. If you have a Database interface with Connect(), Query(), and Shutdown(), but you have a mock object that only needs to simulate Query(), you're still forced to implement Connect and Shutdown just to make the compiler happy.

By using composition, you keep your interfaces "lean." You can write a function that only requires a Reader, and it will work with a ReadWriter, a File, or a NetworkSocket. The more you decompose your interfaces, the more reusable your functions become. It's the "secret sauce" that makes Go's type system feel so flexible despite being statically typed.

Adding Specifics to the Mix

Composition isn't limited to just embedding other interfaces. You can embed multiple interfaces and still add your own unique methods to the composed one. It's not an "either-or" situation.

type Closer interface {
    Close() error
}

// ReadWriteCloser is a powerhouse interface.
// It requires Read, Write, and Close.
type ReadWriteCloser interface {
    Reader
    Writer
    Closer
    Flush() error // A specific method just for this composed interface
}

Now, any type that wants to be a ReadWriteCloser must implement four methods. But the beauty is that Reader, Writer, and Closer remain independent. You can still use them individually throughout your app without dragging the Flush requirement along for the ride.

📋 Practical Task

Implementing a Smart Home Controller

You are building a system to manage smart home devices. Some devices are just Powerable (they can turn on and off), some are Dimmable (they can change brightness), and some are both.

Your task is to:

• Define a Powerable interface with TurnOn() and TurnOff() methods.
• Define a Dimmable interface with a SetBrightness(level int) method.
• Create a composed interface called SmartLight that embeds both Powerable and Dimmable, and adds its own method: SetColor(color string).
• Implement a struct called HueBulb that satisfies the SmartLight interface.
• Write a function called InitializeDevice that accepts a SmartLight and calls all four methods on it to set a default state.