I. Template Method — Behavioral Pattern

Template Method fixes the overall shape of an algorithm in one place, while letting individual steps vary. The sequence of steps — and which ones are fixed versus which ones change — is defined once; only the varying steps are supplied by the caller.

This solves the problem of duplicating an algorithm's skeleton every time one step needs to change. Without Template Method, adding a new variant usually means copying the whole sequence and editing the one step that's actually different, so the fixed parts drift out of sync as each copy gets modified independently over time. Template Method keeps the fixed sequence in exactly one place and isolates the varying parts behind a small contract.

Classic Template Method (in languages with inheritance) puts the fixed algorithm in a base class method and lets subclasses override specific steps. Go has no inheritance, so this example expresses the same idea with a free function that takes an interface: the function Prepare is the template method, and Beverage is the contract for the steps that vary.

II. Real-world Example

A coffee shop where every hot drink is prepared with the same four-step sequence, but the middle steps differ by drink:

1. Beverage (interface) — declares the three steps that vary between drinks: Brew(), PourInCup(), AddCondiments().

2. Prepare (the template method) — a free function that takes any Beverage and returns the four steps in a fixed order: boil water (identical for every drink), then Brew(), PourInCup(), and AddCondiments() — all delegated to whichever Beverage was passed in.

3. Coffee — implements the three steps for coffee: drip through a filter, pour into a cup, add sugar and milk.

4. Tea — implements the same three steps for tea: steep the leaves, pour into a cup, add lemon.

Prepare never changes regardless of which beverage it's given — only the three delegated steps change.

III. Implementation

beverage.go

1package templatemethod
2
3type Beverage interface {
4	Brew() string
5	PourInCup() string
6	AddCondiments() string
7}
8
9func Prepare(beverage Beverage) []string {
10	return []string{
11		"Boiled water",
12		beverage.Brew(),
13		beverage.PourInCup(),
14		beverage.AddCondiments(),
15	}
16}

coffee.go

1package templatemethod
2
3type Coffee struct{}
4
5func (c Coffee) Brew() string {
6	return "Dripped coffee through filter"
7}
8
9func (c Coffee) PourInCup() string {
10	return "Poured coffee into cup"
11}
12
13func (c Coffee) AddCondiments() string {
14	return "Added sugar and milk"
15}

tea.go

1package templatemethod
2
3type Tea struct{}
4
5func (t Tea) Brew() string {
6	return "Steeped tea leaves"
7}
8
9func (t Tea) PourInCup() string {
10	return "Poured tea into cup"
11}
12
13func (t Tea) AddCondiments() string {
14	return "Added lemon"
15}

main.go (usage)

1for _, step := range templatemethod.Prepare(templatemethod.Coffee{}) {
2	fmt.Println(step)
3}
4for _, step := range templatemethod.Prepare(templatemethod.Tea{}) {
5	fmt.Println(step)
6}

IV. Explain the example above

1. templatemethod.Prepare(templatemethod.Coffee{}) runs the fixed sequence: it starts with "Boiled water", then calls Coffee{}.Brew(), Coffee{}.PourInCup(), and Coffee{}.AddCondiments(), collecting all four strings into a slice.

2. The loop prints each step of the coffee sequence in order.

3. templatemethod.Prepare(templatemethod.Tea{}) runs the exact same four-step sequence — the same function, unchanged — but this time steps 2 through 4 delegate to Tea{} instead.

4. The loop prints each step of the tea sequence in order.

Running it produces:

1*** Example Template Method ***
2Boiled water
3Dripped coffee through filter
4Poured coffee into cup
5Added sugar and milk
6Boiled water
7Steeped tea leaves
8Poured tea into cup
9Added lemon

Notice "Boiled water" appears identically in both runs — it's hard-coded inside Prepare and never delegated. Everything else changes based on which Beverage is passed in, without Prepare itself containing a single conditional branch on drink type.

V. Conclusion

Template Method earns its keep when several variants share most of a process and differ only in a few well-defined steps. Fixing the sequence in one place means the shared parts can never drift out of sync between variants, and adding a new variant is just implementing the varying steps — the sequence itself never needs to change or be reviewed again.

The trade-off is rigidity: if a future variant needs to reorder steps, skip one, or insert a new one in the middle, the fixed sequence has to change for everyone, since it isn't part of what varies. For two variants that only share one or two steps in common, keeping them as fully separate functions is often clearer than forcing them through a shared skeleton that barely fits either one. Template Method pays off once the shared sequence is stable and only the delegated steps are expected to grow.

No pattern is universally superior.

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Source code on GitHub