Abstract Factory

The problem

Factory Method makes one product. But sometimes you need a set of products that must be consistent with each other — a pizza’s dough, sauce, and cheese should all be NY-style or all Chicago-style, never a mix. Abstract Factory bundles those creation methods so picking a factory picks a whole coherent family.

Structure

classDiagram
class IngredientFactory {
  <<interface>>
  +Dough() Dough
  +Cheese() Cheese
}
class NYFactory {
  +Dough() Dough
  +Cheese() Cheese
}
class ChicagoFactory {
  +Dough() Dough
  +Cheese() Cheese
}
class Dough { <<interface>> }
class Cheese { <<interface>> }
IngredientFactory <|.. NYFactory
IngredientFactory <|.. ChicagoFactory
NYFactory ..> Dough : thin crust
NYFactory ..> Cheese : reggiano

Idiomatic Go

The client works only with the IngredientFactory interface, so swapping NYFactory for ChicagoFactory swaps the entire ingredient set — and they always match. Edit and Run:

package main

import "fmt"

// Abstract products.
type Dough interface{ String() string }
type Cheese interface{ String() string }

// Abstract factory: makes a whole family of ingredients.
type IngredientFactory interface {
Dough() Dough
Cheese() Cheese
}

// --- NY family ---
type thinCrust struct{}
func (thinCrust) String() string { return "thin-crust dough" }
type reggiano struct{}
func (reggiano) String() string { return "reggiano cheese" }

type NYFactory struct{}
func (NYFactory) Dough() Dough   { return thinCrust{} }
func (NYFactory) Cheese() Cheese { return reggiano{} }

// --- Chicago family ---
type deepDish struct{}
func (deepDish) String() string { return "deep-dish dough" }
type mozzarella struct{}
func (mozzarella) String() string { return "mozzarella cheese" }

type ChicagoFactory struct{}
func (ChicagoFactory) Dough() Dough   { return deepDish{} }
func (ChicagoFactory) Cheese() Cheese { return mozzarella{} }

// Client depends only on the abstract factory — ingredients always match.
func makePizza(f IngredientFactory) {
fmt.Printf("pizza with %s and %s\n", f.Dough(), f.Cheese())
}

func main() {
makePizza(NYFactory{})
makePizza(ChicagoFactory{})
}

A fuller version goes the whole distance: a PizzaIngredientFactory with six creation methods (dough, sauce, cheese, veggies, pepperoni, clam), and NYPizzaIngredientFactory returning ThinCrustDough, MarinaraSauce, ReggianoCheese, and so on. A pizza’s Prepare() simply asks its factory for each ingredient.

Factory Method vs Abstract Factory

Design principle: Dependency Inversion

Abstract Factory is the textbook expression of the Dependency Inversion Principle — depend on abstractions, not concretions. The client (makePizza) names only IngredientFactory, Dough, and Cheese; it never mentions NYFactory or deepDish. So the high-level policy and the low-level concrete families both point at the same abstractions, and neither depends on the other. That inversion is precisely what lets you swap a whole family by passing a different factory value.

In practice an Abstract Factory is often built from Factory Methods (each creation method is one) and frequently hands back a single shared instance via a Singleton — the three creational patterns compose naturally.

In the standard library & ecosystem

Pure Abstract Factory is uncommon in Go’s stdlib (the language nudges you toward simpler construction), but the shape appears wherever a chosen provider yields a matched set — e.g. a database driver producing its own Conn, Stmt, and Tx types, or a cloud SDK whose “client” hands back service-specific request/response objects.

Pitfalls

When to use it — and when not

Related patterns