Factory Method

The problem

When code does d := &MallardDuck{}, it’s welded to that concrete type. Every place that constructs one must change if you add a RubberDuck, and tests can’t substitute a fake. A factory moves the new decision behind a function that returns an interface, so callers depend only on behavior.

Idiomatic Go — the constructor & the Simple Factory

The everyday Go factory is a function returning an interface. A Simple Factory extends that with a switch when the caller chooses a kind at runtime. Edit and Run:

package main

import "fmt"

// Product: callers depend on this, not on concrete types.
type Duck interface{ Quack() }

type MallardDuck struct{}

func (MallardDuck) Quack() { fmt.Println("Quack") }

type RubberDuck struct{}

func (RubberDuck) Quack() { fmt.Println("Squeak") }

type DecoyDuck struct{}

func (DecoyDuck) Quack() { fmt.Println("...silence...") }

// The factory: ask for a kind, get back a Duck.
func NewDuck(kind string) (Duck, error) {
switch kind {
case "mallard":
	return MallardDuck{}, nil
case "rubber":
	return RubberDuck{}, nil
case "decoy":
	return DecoyDuck{}, nil
default:
	return nil, fmt.Errorf("unknown duck: %q", kind)
}
}

func main() {
for _, kind := range []string{"mallard", "rubber", "decoy"} {
	d, err := NewDuck(kind)
	if err != nil {
		fmt.Println("error:", err)
		continue
	}
	fmt.Printf("%-8s -> ", kind)
	d.Quack()
}
}

Factory Method proper — the pizza store

The order workflow is fixed — prepare, bake, cut, box — but which pizza gets created is a step each store provides. In Go (no subclassing), the base store delegates creation to an embedded creator, and NYPizzaStore/ChicagoPizzaStore each supply their own CreatePizza:

classDiagram
class PizzaStore {
  <<interface>>
  +OrderPizza(kind) Pizza
}
class NYPizzaStore {
  +CreatePizza(kind) Pizza
}
class ChicagoPizzaStore {
  +CreatePizza(kind) Pizza
}
class Pizza { <<interface>> }
PizzaStore <|.. NYPizzaStore
PizzaStore <|.. ChicagoPizzaStore
NYPizzaStore ..> Pizza : NY-style
ChicagoPizzaStore ..> Pizza : Chicago-style

// OrderPizza is the fixed workflow; CreatePizza is the factory method.
func (s *PizzaStoreBase) OrderPizza(kind PizzaType) (Pizza, error) {
	pizza, err := s.store.CreatePizza(kind) // varies per store
	if err != nil {
		return nil, err
	}
	pizza.Prepare()
	pizza.Bake()
	pizza.Cut()
	pizza.Box()
	return pizza, nil
}

Each store implements CreatePizza to build its own regional pizzas — same order flow, different products.

The registry variation — Go’s favorite factory

Instead of a hard-coded switch, register constructors in a map keyed by name. New kinds plug themselves in from their own package’s init() — the factory never changes when you add one. This is exactly how image.RegisterFormat, sql.Register, and most codec libraries work:

package main

import (
"fmt"
"sort"
)

type Duck interface{ Quack() string }

// registry maps a name to a constructor, populated at init time.
var registry = map[string]func() Duck{}

func Register(name string, ctor func() Duck) { registry[name] = ctor }

func New(name string) (Duck, error) {
ctor, ok := registry[name]
if !ok {
	return nil, fmt.Errorf("unknown duck: %q", name)
}
return ctor(), nil
}

type Mallard struct{}

func (Mallard) Quack() string { return "Quack" }

type Rubber struct{}

func (Rubber) Quack() string { return "Squeak" }

// In real code each of these would live in its own file/package.
func init() {
Register("mallard", func() Duck { return Mallard{} })
Register("rubber", func() Duck { return Rubber{} })
}

func main() {
names := make([]string, 0, len(registry))
for n := range registry {
	names = append(names, n)
}
sort.Strings(names) // deterministic output
for _, n := range names {
	d, _ := New(n)
	fmt.Printf("%-8s -> %s\n", n, d.Quack())
}
}

The win is open/closed: adding a Decoy duck means writing a new file with a Register call — no edit to New or any switch.

How the creational family compares

All five creational patterns hide new, but they answer different questions:

In the standard library

• sql.Open(driver, dsn) — returns a *sql.DB for a driver registered by name.
• image.Decode — dispatches to a decoder registered via image.RegisterFormat.
• net.Listen("tcp", addr) — returns the right net.Listener for the network.

Pitfalls

When to use it — and when not

Related patterns