Strategy

The problem

A type needs to perform a task that has several interchangeable implementations. The naive approach hard-codes them with a conditional:

func (d *Duck) Fly(kind string) {
	switch kind {
	case "wings":
		// flap...
	case "rocket":
		// ignite...
	case "none":
		// can't fly
	}
}

Every new behavior means editing Fly and growing the switch — the type is closed against extension but you keep opening it. Strategy pulls each algorithm into its own type behind a shared interface, so behavior becomes a value you set, not a branch you add.

Structure

classDiagram
class Duck {
  -flyBehavior FlyBehavior
  +PerformFly()
  +SetFlyBehavior(FlyBehavior)
}
class FlyBehavior {
  <<interface>>
  +Fly()
}
class FlyWithWings { +Fly() }
class FlyNoWay { +Fly() }
Duck o--> FlyBehavior : delegates to
FlyBehavior <|.. FlyWithWings
FlyBehavior <|.. FlyNoWay

The Duck (the context) holds a FlyBehavior and delegates to it. Swapping the concrete behavior changes what the duck does — at runtime, without touching Duck.

How it works

sequenceDiagram
participant C as Client
participant D as Duck (context)
participant F as FlyBehavior
C->>D: SetFlyBehavior(FlyWithWings)
C->>D: PerformFly()
D->>F: Fly()
F-->>D: "Flying with wings"
C->>D: SetFlyBehavior(FlyNoWay)
C->>D: PerformFly()
D->>F: Fly()
F-->>D: "Can't fly"

Idiomatic Go — the interface form

Each behavior is its own type satisfying a tiny interface, and the duck delegates. Edit and Run it:

package main

import "fmt"

// Strategy interface + two implementations
type FlyBehavior interface{ Fly() }

type FlyWithWings struct{}

func (FlyWithWings) Fly() { fmt.Println("Flying with wings") }

type FlyNoWay struct{}

func (FlyNoWay) Fly() { fmt.Println("Can't fly") }

// Context holds a strategy and delegates to it
type Duck struct{ fly FlyBehavior }

func (d *Duck) SetFly(fb FlyBehavior) { d.fly = fb }
func (d *Duck) PerformFly()           { d.fly.Fly() }

func main() {
mallard := &Duck{fly: FlyWithWings{}}
mallard.PerformFly() // Flying with wings

mallard.SetFly(FlyNoWay{}) // swap behavior at runtime
mallard.PerformFly()       // Can't fly
}

You can extend this with a QuackBehavior too, plus concrete MallardDuck and RubberDuck types that embed a base Duck — a great look at composition.

Idiomatic Go — the function form

Here’s where Go diverges from Java. When a strategy is a single operation, you don’t need an interface and a struct at all — a function value is the strategy:

type FlyFunc func()

type Duck struct{ fly FlyFunc }
func (d *Duck) PerformFly() { d.fly() }

mallard := &Duck{fly: func() { fmt.Println("Flying with wings") }}
mallard.PerformFly()
mallard.fly = func() { fmt.Println("Can't fly") } // swap in one line

The principles behind Strategy

Strategy is the Head First Chapter 1 pattern because it distils three of the book’s core principles into one idea:

• Encapsulate what varies — the fly/quack behavior is the changing part, so it’s pulled into its own interface, away from the stable Duck.
• Favor composition over inheritance — the duck has-a behavior rather than is-a subclass, so you mix and match at runtime instead of fixing it in a class tree.
• Program to interfaces, not implementations — Duck depends on FlyBehavior, never a concrete flier.

Its two close cousins are easy to mix up: State has the same shape but the object itself changes its behavior object as it transitions (and states often know each other), whereas a Strategy is chosen from outside and rarely changes itself. Template Method solves a similar “vary the behavior” problem with a fixed skeleton instead of a swappable whole.

In the standard library

• sort.Slice(s, less) — you supply the comparison strategy as a function.
• http.HandlerFunc — an adapter that lets any function be a request-handling strategy.
• strings.Map(mapping, s) — the per-rune transformation is a pluggable strategy.
• template.FuncMap — inject formatting strategies into a template.

Pitfalls

When to use it — and when not

Related patterns